生成AI研究開発チームのainoyaです。
生成AIを活用したコーディングが当たり前の日常になってきた昨今ですが、その強大な力と引き換えに、開発の現場に影を落とす課題も増えてきました。
これまでは考えられなかった速度でコードが生成される一方で、それを受け止める人間の側には「レビュー疲れ」という弊害が生じています。コーディングの速度が上がった結果、人によるレビューの負荷が過剰になりつつあるのです。また、AIが生成するコードの質も無視できない問題です。仕様を満たし動作はするものの、あくまで「その場しのぎ」の実装に留まり、長期的な保守性を損ねたり、チームの実装方針にそぐわないスタイルが紛れ込んだりすることで、コードベースが徐々にカオス化していく懸念があります。
これらは「AI疲れ」として広く認知され始めていますが、放置すればチームの認知負荷はいたずらに消費されるばかりです。コードの出力量は増えたものの、結果としてのアウトカム、すなわち生産性は下がることになりかねません。
もっとも避けたいのは、コードの質が悪化することでレビューが増加し、その疲弊から見落としが発生し、さらにコードの質が下がるという「負のスパイラル」です。
AIを真のチームメイトにするために
では、どうすればAIを単なるツールではなく、チームメイトとして機能させられるのでしょうか。
コーディングエージェントの基本性能が実戦レベルに達してきた今、重要となるのは「いかに良質なコンテキストをエージェントに与えられるか」です。AIを意図通りに動かすための「コンテキストエンジニアリング」の重要性は、もはや論を俟たないでしょう。
ソリューションの1つとして、AI向けの指示（プロンプトやルールファイル）自体を生成AIに作らせるプラクティスもあります。しかし、これらは一般的なベストプラクティスをなぞることに終始しがちで、そのチーム固有のコードベースや現行アーキテクチャ、開発スタイルといった「真に反映すべき文脈」が抜け落ちていることが少なくありません。自動生成された CLAUDE.md などがあまり役に立たないと感じたり、手動でのメンテナンスを推奨する意見（Writing a good CLAUDE.md）が出てきたりしているのも、そうした背景があるからでしょう。
一方で、人間がAI向けの指示を完璧にメンテナンスし続けるのも困難です。更新を忘れて陳腐化したり、そもそも現場の暗黙知をいきなり実用可能な形式知として書き起こすこと自体のハードルが高かったりします。
理想は「コンテキストを開発ナレッジとして自動アップデートするコーディングエージェント」ですが、SaaS内部にナレッジが閉じ込められてしまったり、開発者が個々のローカル環境で好みのエージェントを使う際にコンテキストが共有されなかったりと、運用上の課題が残ります。
我々のチームにおける実践的アプローチ
そこで我々のチームでは、人とAIの協働サイクルをシステムとして回すために、以下の3つのプロセスを連携させた試みを行っています。
全体像としては、以下のようなサイクルを回しています。
graph TD
%% ノード定義
Context("📚 <b>良質なコンテキスト</b><br/>(AGENTS.md / 形式知)")
Implementation("⚙️ <b>1. AI・人の協働による実装</b><br/>(コーディング & AI予備レビュー)")
Review("💡 <b>2. 現地現物での気づき</b><br/>(Humanレビュー / 暗黙知の表出)")
Crystallization("🔄 <b>3. 知識の結晶化</b><br/>(ナレッジの自動更新)")
%% フロー
Context ==>|Input: 的確な指示| Implementation
Implementation -->|Output: たたき台の質の向上| Review
Review -->|Feedback: 重要な思想の発見| Crystallization
Crystallization ==>|Upgrade: コンテキストの進化| Context
%% スタイル調整
linkStyle 3 stroke-width:4px,fill:none;
1. AIコードレビュー
まず導入しているのが、Devinなどのエージェントを活用したコードレビューです。Playbook経由でチームの指示を読み込ませ、GitHub Actionsから起動してレビューを行わせています。
ここではAIにマージの権限（approve）は与えず、あくまで人間の補助として位置づけています。コストはかかりますが、実際にコードをチェックアウトし、内部的な検証や実行を行った上での指摘となるため、コメントの質は非常に高いものになっています。他のAIレビューツールで生じた誤りをDevinが訂正することさえあるほどです。(とはいえ、より効率の良いレビューツールについて日々検討しています。)
2. レビュー自動修正のAIコマンド
次に、開発者の手元で実行するAIコマンドによる修正支援です。これはPRについたレビューコメントを取得し、対応コードを生成するものです。
完全に自動で修正させることも可能ですが、我々はあえて「修正内容の確認」と「コードベースへの変更差分の認識」を人間が行うプロセスを残しています。レビュワーとレビュイー双方が変更内容を正しく理解しておくことが重要だと考えているからです。
レビューを自動修正するAIコマンドの例
--- description: GitHubの未解決レビューコメントを取得し、指摘内容を踏まえてコード修正まで完遂する指示 --- # Pull Requestの未解決レビューコメントを取得し、指摘内容を踏まえてコード修正まで完遂する指示を行います 以下の手順に厳密に従ってください。 1. **未解決レビューコメントの取得** - `fetch-unresolved-review-comment.sh` を実行し、対象PRの未解決レビューコメント一覧を取得してください。 - コメントが存在しない場合は、その旨を記録して終了してください。 2. **指摘内容の整理** - 各コメントの URL、対象ファイル、該当行、レビュアーの意図を明確に整理してください。 - 複数のコメントが同一箇所に関係する場合は、重複を統合しつつ矛盾がないか確認してください。 3. **コード修正の実施** - 指摘を解消するための修正方針を決定し、必要に応じて関係ファイルを開いて差分を確認してください。 - コードを編集する際は、指摘の背景や判断理由がわかるように日本語で丁寧なコメントを追記してください（既存方針に従い、不要な場合はコメントを控えてもよい）。 - 影響範囲を確認し、関連するテスト・型定義・ドキュメントも必要に応じて更新してください。 - 複雑な変更の場合は段階的にコミットできるよう、意識して変更を分割してください。 4. **最終確認と共有** - すべてのコメントについて対応が完了しているか確認し、未解決が残る場合はレビュアーに質問する準備を整えてください。 - 対応内容の要約と追加で共有すべき事項（レビュアーへの確認要否など）があれば、最後に箇条書きで記録してください。 5. **注意事項** - 指摘が誤解に基づいていると判断した場合は、その根拠と代替案を明記した上で確認してください。
※ scripts/fetch-unresolved-review-comment.sh の詳細については簡単なスクリプトのため割愛しますが、gh api等を使用してレビューコメントを収集するスクリプトです。
3. 人が行ったレビューのAI向け指示への反映
そしてもっとも重要なのが、人が行ったレビューをAIの知識として還流させるプロセスです。
任意のタイミングでDevinに依頼を行い、PRについた「人間によるレビューコメント」を一括取得します。そこで得られた知見がまだAI向け指示（AGENTS.mdなど）に反映されていない場合、それを新たなルールとして追加・更新するPRを自動作成します。
ルール更新PRによって、以下のような知見がコンテキストとして蓄積されていきます。生成されたルールによっては、AI向けの指示ではなくLinterによる静的解析が適切な場合もあるため、その場合は別途Linterルールを整備します。また、より良質な指示にするために、人間が内容を確認・修正してからマージするフローを採用しています。
@@ -87,6 +87,10 @@ backend
+ - エラーのテストでは、エラーメッセージの文字列ではなくエラークラス（instanceof）で比較する
+ - 理由: エラーメッセージは変更される可能性があり、文字列比較は脆弱
+ - 良い例: `expect(result).rejects.toThrow(ChatNotFoundError)`
+ - 悪い例: `expect(result).rejects.toThrow("Chat not found")`
知識創造のループを回す
この仕組みを導入した結果、明確な効用が得られました。
AIによる網羅的なレビューが人間のレビューの下敷きとなることで、多少差分が多くても効率的にチェックが進み、レビュー疲れが軽減されました。また、手元の自動修正コマンドが指摘対応のハードルを下げ、「対応に時間がかかるから後回しにし、結局忘れる」という事態もなくなりました。
何より大きいのは、「無理なく形式知への変換を行えるようになった」ことです。
暗黙知とは本来、実戦の場において表出するものです。PRレビューという「現地現物」の場における知識の共同化の中で、レビューコメントとして現れた暗黙の知識。これをシステムが定期的に収集・形式化し、AI向け指示として内面化（アップデート）する。この一連のプロセスが、人間が意識せずとも自然に回るようになりました。
まとめ
これら一連の仕組みは、開発におけるポジティブなフィードバックループを生み出し、知的創造サイクルを加速させています。現場の暗黙知が形式知になり、それによってより良質なコンテキストが生まれ、コードベースとレビューの質が向上し、さらに高度な暗黙知が形式知へと還元されていく。このループこそが、結果としてのアウトカム向上につながると考えます。
広木大地氏の著書『AIエージェント 人類と協働する機械』でも、AIによって仕事の処理速度が上がるほど、人間の意思決定は高密度化し、認知負荷がボトルネックになるという問題構造が示されています。
重要なのは、AIで“作業”を減らすことではなく、暗黙知が生まれる現場を起点に、それを循環させ続ける仕組みを設計できるかどうかです。PRレビューという現地現物の場で生まれた判断を、形式知としてAIに還流させる。そのループを回し続けることで、AIは単なる生産性向上ツールではなく、知識創造を加速する真のチームメイトになっていくのだと思います。
