✔この記事の対象者
- インナーソースやOSSのコントリビュート文化に興味がある方
- 社内でAIエージェントとGitHub Actionsを組み合わせた「IssueOps」を検討している方
こんにちは、エンジニアリングマネージャーの芦川です。
以前からいろいろとインナーソースに関連した話を書いてきました。
- インナーソースが組織に広がりやすいパターン4選！
- GitHubで育つコラボレーション文化 :ニフティでのインナーソース挑戦事例
- ドキュメントライティング本をインナーソースの観点から読んでみた
- InnerSource Summit 2025にて写真撮影サポート ＆ 登壇させていただきました！
など。
あれから月日が経ち、AIの活用で社内のインナーソースの形そのものが少しずつ変わってきています。
今回書きたいのは、インナーソース x IssueOps x AIということについてです。
インナーソースはIssueOpsによって加速し、さらにAIによってIssueOpsも加速したな、ということ。
これまでのインナーソースの話
これまでのインナーソースは、OSSのコントリビュートフローをそのまま社内に持ち込んだような形でした。
- コントリビュートしたいリポジトリの権限をもらう（あるいはフォークする）
- コードを読んで、修正方針を考える
- 実際にコードを直す
- アップストリームへPRを出す
- リポジトリのオーナー側がレビューする
- マージされる
この流れは「エンジニアがエンジニアに対して」行うことが前提になっていて、次のような壁がありました。
- 対象リポジトリの技術スタックに慣れていないと、そもそも着手しづらい
- Gitの操作（ブランチを切る、PRを出す）に慣れていない人は参加すらできない
- 「他チームのリポジトリにPRを出す」ということ自体に、なんとなく気後れしてしまう
IssueOpsがインナーソースを変え、AIが加速させてくれた
「Issueを起票すると自動でPRができる」という仕組み自体は前から存在していました。決まった書式のIssueテンプレートを用意しておき、そこに入力された内容をスクリプトが読み取って、設定ファイルを自動編集してPRを作る。いわばルールベースのIssueOpsです。
これはこれで十分便利で、たとえば
- 権限申請のような、入力項目が決まりきった依頼
- 特定のフォーマットのデータ連携定義を追加するような、パターン化しやすい依頼
にはとても有用です。わざわざ、リポジトリをcloneする作業も不要なので敷居を下げたインナーソースとしても以前からうまくハマり、実際に社内でも、こうした申請系の作業を自動化する取り組みは、AIエージェントが普及するより前から動いていました。
ただし、ルールベースである以上、対応できるのは「あらかじめ想定した書式・パターン」の範囲までです。少し込み入った依頼や、自然文でしか説明しづらい要望には対応できませんでした。
そこにAIエージェント（Claude Codeのようなコーディングエージェント）が加わったことで、状況が変わりました。
ルールベースの時代とAI時代の一番の違いは、Issueに入力する内容が「スクリプトがパースできる、かっちり決まったフォーマット」である必要がなくなったことだと思っています。以前は、項目名・選択肢・区切り文字まで含めて厳密に決めておかないと、後段の処理が動きませんでした。AIエージェントであれば、多少表現がゆれていても、あるいは自然文でだらだら書いてあっても、意図を読み取ってコードに落とし込んでくれます。
乱暴に言ってしまえば、日本語で「こうしてほしい」と書くだけでPRまで自動生成される、というところまでコントリビューターの敷居が下がったのが、今回の変化の本質です。つまり、IssueOpsという土台自体は以前からあったものを、AIがIssueOpsを自由にし、結果的にインナーソースを加速させる、というのが今の状況だと捉えています。
まあ流石に何でも自然文で通ってしまうと、意図しない範囲まで書き換えられてしまうリスクもあるため、どこかにガードレール（変更してよい範囲やレビュー必須のルールなど）を設けておくことは絶対必要です。
この3段階の変化を図にすると、こんな感じです。
見た目のステップ数はあまり変わっていないのですが、オレンジ（人がやる作業）がだんだん減って、青（自動化されている作業）に置き換わっているのがわかると思います。ルールベースの段階ですでに一部は自動化されていて、AIが加わったことで、起票そのものが自然文でよくなり、対応できる範囲も一気に広がりました。
実際どう使われている？
ずばり、こういうissueテンプレートです。これはプラットフォームチームが持つ定義ファイルに、社内連携システム側から定義変更の依頼を受け付けるものです。
変更内容と補足・備考あたりは、自然文を書いてもらい、その後、Claude Code GitHub Actionsを使ってPRまで作るということになります。
利用した人からは「簡単に依頼が出せた、フォーマットも迷わなかった」という声をもらえました。
とはいえ、いいことばかりではなく課題はあります。
課題
AIのコストを負担するのが誰なのか、という問題
ルールベースのIssueOpsは、実行コストがほぼスクリプトの実行時間だけだったので、あまり意識されていませんでした。ところがAIエージェントが実装まで担うようになると、そのコストが無視できない金額になってきます。これまでのインナーソースでは、コードを書くコスト（工数）はコントリビュートする側が負担していましたが、IssueOpsではその工数がAIエージェントの実行コストに置き換わり、しかもそのコストは多くの場合「リポジトリを持っている側」が負担することになります。
定義変更レベルでは消費されるトークンは少なくこのままでも問題なさそうですが、より大規模なPRとなっていく場合は議論しなければいけません。
意図とズレたPRが生成されることがある
自然文で起票できる分、自由度は高いのですが、AIが依頼内容を誤解して、意図と違う実装のPRを作ってしまうことも当然あります。実際に「IssueOpsで作られた設定が少しおかしかったので、直すPRを出しますね」という会話も社内でありました。結局、リポジトリを持っている側が手直しをすることになったわけです。ルールベースの時代にはこうした「解釈のズレ」はほぼ起きなかったので、これはAIが加わったことで新しく生まれた課題だと言えそうです。ただ、修正を加味しても楽にはなりました。
自然文の自由度には、ガードレールをセットで
ヘタをするとリポジトリを破壊するPRも作ってしまう可能性がありますので、何らかのガードレールは必要だと感じています。たとえば：
- AIが編集してよいファイル・ディレクトリを限定する
- 本番直接反映ではなく、必ずPR経由で人のレビューを挙してからマージする
- バリデーションやCIを通さないとマージできないようにする
- どこまでをAIに任せてよいか（実装方針の判断まで任せるのか、定型的な修正に限定するのか）をリポジトリごとに決めておく
このあたりは、IssueOpsの本体である「.github/workflows/xxx.yml」内のpromptなり、「claude/skills/xxx/SKILL.md」なりでしてはいけないことを明示しましょう。
まとめ
狭い意味でのインナーソース（フォーク → 修正 → PR → レビュー → マージ）は、まずルールベースのIssueOpsによって一部が自動化され、そこにAIエージェントが加わったことで、
Issueに自然文で起票 → AIがコードを修正してPRを作成 → レビュー → マージ
という形にまで進化しました。「IssueOpsという土台は以前からあり、AIがそれを加速させた」というのが、この1〜2年の変化を一番よく表しているように思います。コントリビュートする側に求められるハードルが「自然文を書くこと」まで下がったことで、これまでリーチできていなかった人たちからの貢献が生まれています。
一方で、AIのコスト負担がリポジトリを持つ側に偏ってしまったり、意図とズレたPRが生成されてしまったりと、新しい種類の課題も出てきています。それでも全体として見れば、チームの内外でのコラボレーションを活性化させる、良い方向に進んでいるのではないかなと思っています。
まだまだ事例は増え続けると思います。何かインナーソース関連を見かけたらまた書きたいと思います。
