はじめに：極端な言説は、設計判断の出発点にすぎない
「AIが生成したコードは読まなくていい」「RAGは死んだ」「SkillsがMCPを駆逐した」——生成AIをめぐっては、短く断定的な意見が日々登場します。
こうした“ホットテイク”は、議論のきっかけとしては有効です。しかし、実際の開発現場にそのまま持ち込むと、技術の選定やレビュー方針を誤る可能性があります。
GitHubの解説が示している重要なポイントは、これらの技術や考え方を単純な勝ち負けで捉えないことです。問うべきなのは「どちらが優れているか」ではなく、どの課題を、どの条件で解決する技術なのかです。
本記事では、AIエージェント、MCP、Skills、RAG、そしてAI生成コードのレビューを、ソフトウェア開発の実務という観点から整理します。
AI生成コードは「すべて読む」のではなく「結果を所有できるまで読む」
AIがコードを書いたとしても、最終的な責任が開発者から消えるわけではありません。生成コードを採用したことで発生した障害、脆弱性、性能問題は、通常のコードと同じようにチームが引き受けます。
一方で、生成されたすべての行を同じ密度で読む必要があるわけでもありません。重要なのは、変更のリスクに応じてレビューの深さを変えることです。
| 変更内容 | 重視すべきレビュー観点 |
|---|---|
| CSSの試作や画面上の小さな調整 | 見た目、既存レイアウトへの影響、不要な複雑化 |
| 単純なテストコードの追加 | テスト対象、失敗条件、テストの独立性 |
| データアクセス処理の変更 | 権限、入力値、クエリ、エラー処理、性能 |
| 認証・認可のリファクタリング | 境界条件、権限昇格、セッション管理、監査ログ |
| 決済や個人情報を扱う機能 | セキュリティ、可用性、監査可能性、障害時の復旧 |
レビューでは、単にコードを目で追うだけでなく、次の問いに答えられる状態を目指します。
- この変更は何を保証するのか
- どの入力や状態で失敗するのか
- エラーが発生した場合、利用者やデータに何が起きるのか
- 権限や個人情報の扱いに問題はないか
- 既存のテストは変更の意図を十分に表しているか
- 半年後に別の開発者が修正できる構造になっているか
AIに実装を依頼する前に、既存コード、依存関係、境界条件を把握しておくことも有効です。先に「どうあるべきか」を理解していれば、生成結果の誤りを発見しやすくなります。
つまり、AIはレビューを不要にするのではなく、レビューすべきポイントを見つけるための判断力をより重要にするツールです。
AIを使える人材とは、ツールを触った人ではない
採用やチーム運営において、「AIを使った経験があるか」だけを評価軸にすると、実務能力を見誤る可能性があります。
より重要なのは、候補者や開発者が次の点を説明できることです。
- どの作業でAIを使い、どの作業では使わないのか
- 生成コードをどのような基準でレビューするのか
- 速度、品質、セキュリティ、保守性のトレードオフをどう考えるのか
- AIの出力が不適切だった事例と、その修正方法
- ツールやモデルが変わったときに、開発プロセスをどう見直すのか
AIを全面的に拒否することも、AIに判断を全面的に委ねることも、安定した開発プロセスにはなりにくいでしょう。求められるのは、AIを使うことそのものではなく、AIを使う範囲と、人間が判断を保持する範囲を設計する能力です。
SkillsとMCPは競合関係ではない
「SkillsがMCPを置き換える」という見方は、両者の役割を同じものとして扱っています。しかし、解決している問題は異なります。
| 技術・概念 | 主な役割 | 例 |
|---|---|---|
| MCP | エージェントとツール・データを接続するための標準的なインターフェース | チケット管理、ファイル、社内データへのアクセス |
| Skills | 作業手順、プロジェクト固有の知識、チームの規約を伝える | コーディング規約、リリース手順、障害対応の進め方 |
| RAG | 外部の文書やデータから関連情報を取得して回答や処理に利用する | APIドキュメント、過去の障害記録、製品仕様 |
| AIエージェント | 上記の仕組みを組み合わせて、複数の処理を進める主体 | 調査、実装、テスト、報告の連続実行 |
MCPは「何に接続できるか」を整えます。Skillsは「接続したものを、どのような方針で使うか」を伝えます。RAGは「必要な情報をどこから取り出すか」を支援します。
たとえば、障害対応エージェントを考えてみます。
- Skillsが、障害対応の手順やエスカレーションルールを示す
- MCP経由で監視システムやチケット管理システムに接続する
- RAGで過去の障害記録や関連ドキュメントを検索する
- エージェントが状況を整理し、指定された形式で報告する
この構成では、どれか一つが他を駆逐する必要はありません。標準化された接続、業務固有の知識、関連情報の検索を分担させることで、システム全体の責務が明確になります。
RAGは死んだのではなく、目立たなくなっただけ
RAGは、モデルの学習時点に含まれていない情報や、組織内の最新情報をAIに与えるための基本的な手法です。対象には、製品仕様、社内ドキュメント、サポート履歴、コードベースの情報などが含まれます。
エージェントやSkillsが注目されると、RAGが古い仕組みに見えることがあります。しかし、エージェントが適切な判断をするには、依然として関連性の高い情報が必要です。検索品質が低ければ、エージェントの計画やツール呼び出しも不正確になります。
RAGを評価するときは、単に「検索できるか」ではなく、次の観点を確認することが重要です。
- 質問に対して関連する文書を取得できるか
- 古い情報や重複した情報が優先されていないか
- 文書の権限管理を維持できているか
- 検索結果の出典を追跡できるか
- 取得した情報が回答や処理に実際に利用されているか
- 文書の分割やメタデータが検索目的に合っているか
RAGの課題は、RAGという名前を使うかどうかではありません。必要な情報を、適切な権限で、十分な精度と速度で取り出せるかです。
コードベースの可読性は、AI時代の開発基盤になる
AIがコードベースを理解できないとき、原因はモデルの能力不足だけとは限りません。構造が複雑で、命名が一貫せず、テストやドキュメントが不足していれば、新しく参加した人間の開発者も理解に時間がかかります。
AI支援開発は、コードベースの保守性を測る新しい圧力テストになり得ます。特別なモデル調整を行う前に、次のような改善を検討できます。
- モジュールや関数の責務を小さく保つ
- 変数名やAPIの命名規則を統一する
- 複雑な処理の意図をコメントやドキュメントで説明する
- 入出力と失敗条件が分かるテストを書く
- 古くなったドキュメントを整理する
- 暗黙の前提を設定ファイルや型、バリデーションで明示する
- 依存関係やデータの流れを追跡しやすくする
ファインチューニングが有効なケースはありますが、それによって保守性の問題を覆い隠すべきではありません。まず人間にもAIにも意図が伝わるコードを作り、そのうえで必要な最適化を検討する方が、長期的には扱いやすいでしょう。
実務で導入するときの判断フレームワーク
AIエージェントや関連技術を導入する際は、流行している技術名から始めるのではなく、業務上の課題から逆算します。
- 自動化したい作業と、許容できる失敗の範囲を定義する
- 作業に必要な外部システムやデータを洗い出す
- 接続の標準化が必要ならMCPのようなインターフェースを検討する
- チーム固有の手順や判断基準をSkillsとして整理する
- 最新情報や社内知識が必要ならRAGを組み込む
- 変更や実行の前に、人間による承認が必要な箇所を決める
- 成功率だけでなく、誤操作、権限逸脱、保守コストも評価する
特に本番環境への書き込み、権限変更、個人情報の処理などは、AIが自律的に実行できるかではなく、どの段階で人間の確認を必須にするかを先に決めるべきです。
まとめ：技術の勝敗ではなく、責務の分担を見る
今回の論点から得られる実務上の結論は明快です。
- AI生成コードは、リスクに応じた深さでレビューする
- AI活用人材には、利用経験より判断基準と説明力を求める
- MCPは接続、Skillsは手順や知識、RAGは関連情報の取得を担う
- RAGはエージェント時代にも、最新情報や社内知識の基盤として機能する
- 人間にもAIにも理解しにくいコードは、まず保守性の問題として扱う
「RAGは死んだ」「SkillsがMCPを置き換えた」といった表現は、議論を始めるには便利です。しかし、実際の開発で必要なのは、スローガンへの賛否ではありません。
小さなプロトタイプを作り、どの情報が不足し、どの処理で失敗し、どこに人間の判断が必要だったのかを記録する。その結果をもとに、構成と運用を改善する。AI開発で価値があるのは、強い意見を繰り返すことではなく、現場で検証できる仕組みに落とし込むことです。
出典： GitHub Blog