「開発にもっとAIを活用できないか」——自社プロダクトを持つ開発責任者なら、一度は考えるテーマだと思います。私たちも、GitHub の Issue に @claude と書くと、AI がコードの下書きや修正を行って PR を作る——そんな仕組みを GitHub Actions で自社リポジトリに組み込みました。

結論から書くと、仕組みとしては動いたものの、運用としては定着しませんでした。この記事では、どう権限を設計したかに加えて、なぜ使われなくなったのかまで正直に記録します。同じものを入れようとしている方が、実装より先に考えるべきことが見えるはずです。技術の手順そのものより、判断と、その後の顛末に軸を置きます。

筆者（馬込）は、少人数で複数の自社プロダクトを開発・運用してきました。AIを開発に組み込む取り組みも実際に手を動かして試しており、その中には「作ったのに使われなかった」ものも含まれます。うまくいった話だけでなく、この種の失敗こそ、これから導入する人の判断材料になると考えています。

なぜAI開発支援をCIに組み込もうとしたか

前提は、少人数で複数プロダクトを回している状況でした。AIに開発を手伝わせたい。ただし素朴に「全部やらせる」のは危うい。求めたのは次の2点です。

  • 定型的な修正や下書きは、人の手を介さず進めてほしい
  • ただし、何をどこまで触れるかは制御したい（勝手に何でも実行されると困る）

言い換えると、これは「AIに権限を渡す」実装であり、どこまで渡すかの設計が本体でした。CIに組み込めば、Issue に指示を書くだけで実装が進む——その非同期な自動化に期待したのです。

権限設計——「間違えても人が戻せるか」で絞る

設計の中心は、AIに与える権限をどう絞るかでした。判断の軸は一貫していて、「間違えたときに、人が気づいて戻せるか」。この一点で3つを絞りました。

絞る対象 選んだ設定 理由
トリガー Issueコメントの @claude のみ あらゆるイベントで動くと事故る。Botのコメントには反応させない（無限ループ防止）
使えるツール ファイル編集のみ許可・シェル実行は禁止 ファイル編集は差分で気づけるが、任意のシェル実行は気づけない
トークン GitHub App で都度発行 権限スコープをApp側で管理し、必要な権限だけを与える

実際の設定でも、AIに許可するツールを明示的に絞っています。

# AIに許可するツールを絞る（ファイル編集のみ・シェル実行は禁止）
allowed_tools: "Edit,Replace"
disallowed_tools: "Bash"

特に効いたのは2行目です。CI上で任意のシェルを実行できる状態は、権限として強すぎます。「ファイルを編集してPRを出す」だけなら編集権限で足り、間違えても差分レビューで戻せます。気づけない操作は最初から渡さない——これが権限設計の芯でした。

トリガーの絞り込みにも、地味だが重要な落とし穴があります。GitHub では PR のコメントも Issue のイベントとして飛んでくるため、明示的に弾かないと意図しない文脈で動きます。Bot のコメントに反応させないガードも、入れておかないと後で必ず踏みます。

この「Issue のイベントが PR からも飛んでくる」性質から、もう一つの判断が生まれました。用途ごとにワークフローを分けることです。「Issue で指示を受けて実装しPRを作る」仕組みと、「PRでコードレビューする」仕組みを、1つのジョブで両方捌こうとすると条件分岐が複雑になり、「いま、どちらの文脈で動いているのか」が読めなくなります。トリガーの意味が違うなら、ワークフローも分ける——見た目は重複しても、そのほうが結果的に読みやすく、事故も追いやすくなりました。これも運用して腹落ちした判断です。

動いたのに使われなかった3つの理由

ここからが本題です。仕組みは動きました。Issue に @claude と書けば PR が作られる。デモとしては成立していました。**しかし、日常的にはほとんど使われませんでした。**理由を振り返ると、いずれも実装の問題ではありませんでした。

① 手元の対話のほうが速い。 エディタ上でAIと対話しながら書くほうが、Issueにコメントしてワークフローの完了を待つより圧倒的に速い。Issueに書いて数分の実行を待つより、その場で対話して直すほうが体感で何倍も速い——この当たり前を、仕組みを作ってから思い知りました。CI経由の価値は「非同期でよい作業」にありますが、開発の大半は同期的に進めたい作業でした。ここの見立てが甘かったのです。

② 設定が陳腐化した。 プロジェクト固有の前提（技術スタック・構成・方針）をワークフローに書き込んでいました。しかしプロジェクトは変わります。書いた瞬間から古くなるものを、設定ファイルに埋め込んでしまった。後から見ると、旧プロダクト名や既に存在しないファイルへの言及が残っていました。

③ 使う理由が手順に組み込まれていなかった。 これが最大の要因です。「使ってもいい仕組み」は、たいてい使われません。使わないほうが面倒、という状態まで手順に織り込めていなかった。導入した時点で満足してしまい、日々のフローに馴染ませる工程を省いたのが原因でした。この構造は、生成AI機能を作っても運用に乗らない状況ともよく似ています（「生成AIのPoCが本番に上がらない理由」も同じ根を持ちます）。

教訓——「どこで使うか」を実装より先に決める

この経験から得た教訓は、実装の前段にあります。

  • CIにAIを組み込む価値は「非同期でよい作業」に限る。 同期的に進めたい作業なら、手元の対話のほうが速い。まずここを見極める。
  • プロジェクト固有の前提を設定に埋めない。 陳腐化して、誰も直さない。参照する形にするか、そもそも書かない。
  • 「使う理由」を手順に組み込むところまでが実装。 入れて終わりだと、動く仕組みが静かに放置される。

技術的には難しくありません。トリガーを絞り、権限を絞り、トークンを安全に発行する——これだけです。難しいのは、それをどこで使うのかを先に決めることでした。AIをどこまで開発に入れるかの線引きは、CIに限らず「間違えても戻せる作業から」という同じ基準で判断できます。

TechMateのAI活用・開発体制づくり支援

私たちTechMateは、こうした生成AIの実装や開発体制づくりを、月単位の準委任で伴走しています。「入れる」だけでなく「使われ続ける」ところまでを設計に含めて並走します。AI活用や開発の相談はこちらからどうぞ。

よくある質問

Q. AIコード生成をCIに組み込むと、品質は担保できますか？ A. 「間違えても人が戻せる範囲」に権限を絞れば、リスクは管理できます。ファイル編集に限定し、差分レビューを必ず通す運用にすれば、暴走はPRの段階で止まります。逆に、任意のコマンド実行まで許すと気づけない事故が起きうるため、そこは渡さない設計が前提です。

Q. 結局使われなかったなら、CI組み込みは無駄だったのでしょうか？ A. 無駄ではありませんでした。「どの作業が非同期に向くか」を実地で見極められたことが収穫です。同期的に進めたい作業には手元の対話、非同期でよい作業にはCI、という住み分けが見えました。失敗の価値は、次に何を作るべきでないかが分かることにあります。

Q. これから導入するなら、何から決めるべきですか？ A. 実装より先に「どの作業を、なぜ非同期にしたいのか」を一つ具体的に挙げてください。そこが埋まらないなら、たぶん使われません。ツールの設定は後からでも変えられますが、使う理由は最初に手順へ組み込む必要があります。

GitHubにAI開発支援を組み込むこと自体は、技術的に難しくありません。難しいのは、それをどこで、なぜ使うのかを実装より先に決めることでした。私たちはそこを省いて「動く仕組み」を作り、静かに放置しました。同じ轍を踏まないための、ひとつの記録として役立てば幸いです。

自社の開発にAIをどう組み込むか迷う段階でも構いません。AI活用・開発体制のご相談から、お気軽にお問い合わせください。