［開発者向け］「AIコードは読まなくていい」は本当か——GitHubが斬る5つの俗説

2026-09-22

はじめに

　GitHubは2026年9月18日、AI開発をめぐる「ホットテイク」を検証するGitHub Podcastの最新エピソードにあわせて、5つの俗説を取り上げる記事を公式ブログで公開しました。本稿ではこの内容をもとに、それぞれの俗説の妥当性と実務での考え方を紹介します。

参考記事

タイトル: Should you read the code, is RAG dead, and did Skills kill MCP?
著者: GPS(@madebygps)
発行元: The GitHub Blog
発行日: 2026年9月18日
URL: https://github.blog/ai-and-ml/should-you-read-the-code-is-rag-dead-and-did-skills-kill-mcp/

要点

GitHubは、AI開発をめぐる5つの「ホットテイク(断定的な意見)」を検証する記事を公開した。
AI生成コードを読まなくてよいという主張には反対し、説明・保有責任を持てるまでレビューする姿勢を推奨している。
MCPとSkillsは競合するものではなく、MCPが標準化されたツール接続を、Skillsが文脈や手順の共有を担うと整理している。
RAG(検索拡張生成)は死んでおらず、エージェント・Skills・MCPと組み合わせて使われる技術だと位置づけている。
コードベースがAIに理解されにくいなら保守性の問題であり、モデルの微調整より構造の見直しを優先すべきだとしている。

詳細解説

俗説1: 「AI生成コードは読まなくていい」

　GitHubは、この主張に明確に反対しています。コードを生成したのがAIであっても、その結果に対する責任は開発者にあるためです。ただし、すべての変更が同じ水準の注意を必要とするわけではないとも指摘しています。本番環境の認証まわりのリファクタリングと、CSSの実験的な変更とでは求められるレビューの厳格さが異なり、10年保守してきたコードベースと今朝開いたばかりのコードベースとでは判断の勘所も変わってくるとされています。

　GitHubが示す簡潔な基準は、「結果を説明し、自分の責任として引き受けられるところまでレビューする」ことです。作業によっては、エージェントがコードを書く前に既存の実装を読み、依存関係を洗い出し、エッジケースを特定して計画を立てる段階の方に労力がかかることもあれば、生成されたコードのエラー処理・権限・データアクセス・性能・アクセシビリティ・テストの確認に大半の注意を割くべき場合もあるとされています。本稿としては、AIは作業そのものをなくすのではなく、労力のかかる場所を移動させるだけであり、その移動先を見極める判断力こそが問われていると受け止めています。

俗説2: 「AIを使わなければ採用されない」

　GitHubは、この主張についても単純化しすぎだとしています。より多くの企業が候補者にAIの使い方を尋ねるようになっているのは事実ですが、全員が同じワークフローや同じ熱量でツールを使うべきだと考えている企業はほとんどないとされています。

　重視されるのは、AIをいつ使い、いつ手作業に切り替えるかを説明できるか、生成されたコードをどうレビューするかを述べられるか、速度・品質・セキュリティ・保守性について率直に語れるか、ツールの変化に合わせて自分の進め方を変えられるかといった「判断力」だとされています。AI関連の製品を作る企業や、エンジニアリングでAIを多用する企業であれば、AIに触れない姿勢が不利に働くことはあり得るとしつつも、AIへの全面依存と全面拒否のいずれも、良い答えにはなりにくいと整理されています。

俗説3: 「SkillsがMCPを終わらせた」

　GitHubは、この主張も否定しています。MCP(Model Context Protocol、本ブログでも最新仕様の変更を紹介しましたが、エージェントがツールやデータに接続するための標準規格)と、Skills(IBMが「手続き記憶」という発想で解説していたように、チームの働き方やプロジェクトの進め方、ツールの使い方といった「パッケージ化された専門知識」)は、そもそも解決する課題が異なるためです。

　MCPは、システム同士を確実に連携させたいときに重要になる標準規格で、エージェントがツールを構造化された形で呼び出し、文脈を取得し、行動を起こすための手段を提供します。SkillsはMarkdownで書かれることが多く、人間にも読める点が価値の一部になっているとされ、MCPがアクセス手段を提供するのに対し、Skillsはそのアクセスをどう活用するかを説明するものだと整理されています。GitHubは、どちらか一方を選ぶ必要はなく、共有インターフェースには標準規格を、文脈・プロセス・ベストプラクティスにはSkillsを使い分ければよいとしています。

俗説4: 「RAGはもう終わった」

　GitHubは、RAG(検索拡張生成、モデルの学習データに含まれない情報を外部から取得して回答に反映させる技術)が終わったわけではなく、単に話題性が薄れただけだとしています。適切な検索がなければ、モデルは自身の知識に頼るか、文脈を探すために余計な時間を費やすことになり、トークンの浪費や作業の遅延、不完全な回答につながるとされています。

　良い検索は、モデルを答えに近い位置からスタートさせ、探索範囲を絞り込み、実際に関係する情報に回答の根拠を置く助けになるとされています。GitHubは、エージェント・Skills・MCP・RAGはいずれも同じワークフローの中で共存でき、たとえばエージェントがMCPでツールにアクセスし、Skillsでプロジェクト固有の指示に従い、RAGで裏付けとなる文脈を見つけるといった組み合わせが実際にありうると説明しています。

俗説5: 「コードベース向けに微調整が必要なら、そのコードは悪い」

　GitHubは、モデルを微調整すべき正当な理由がある場合もあるとしつつ、現代のモデルは一般的なフレームワークや命名規則、アーキテクチャを大量に学習しているため、モデルがコードベースを理解できないなら、新しく加わったチームメンバーも同様に苦労する可能性が高いと指摘しています。

　AIは、コードレビューやテスト、オンボーディング、数ヶ月後にバグを追う担当者と同様、保守性を試す新たな圧力になりつつあるとされています。明確な構造、一貫した命名規則、読みやすいテスト、有用な抽象化、最新のドキュメントは、いずれもエージェントにとって理解しやすいコードベースを作るだけでなく、人間にとってのレビュー・デバッグ・拡張のしやすさにもつながるとされています。

議論より実践を——2つのプロジェクト事例

　GitHubは、こうした議論に決着をつける最善の方法は、さらなる意見を重ねることではなく、実際にアイデアを試し、何が起きたかを記録することだとしています。例として、貢献者がプロジェクトの改善を通じて「pollen」と呼ばれるクレジットを得られる生成AIプラットフォーム「Pollinations AI」と、マイクとRaspberry Pi、電子ペーパー、3Dプリント部品、生成した鳥の画像を組み合わせ、バルコニーに訪れる鳥を壁アートに変える記録プロジェクト「Avian Visitors」が紹介されています。GitHubは、これらのプロジェクトが議論に決着をつけるわけではないものの、証拠を作り、トレードオフを明らかにし、他の人が始めるきっかけになると評価しています。