AIエージェントの基本から学ぶ「AIコーディング」実践入門
―Claude Codeを使いこなす3つの原則

弊社CEOの西見が2026年4月9日に東京ビッグサイトで登壇した内容をもとに、AIコーディングの定義、代表的な課題、実務で活用するための3原則を紹介します。

イントロダクション：ツールを使いこなす発想から、AIエージェントが働きやすい環境設計へ

Claude Codeを使いこなす上で必要なのは、思考のパラダイムシフトです。

従来のソフトウェアでは、利用者が機能や操作方法を理解し、ツールを正しく使いこなすことが重視されてきました。しかし、Claude Codeは従来のソフトウェアとは異なります。Claude Codeの本質は、与えられた目的に応じて状況を判断し、必要な作業を自律的に進めるAIエージェントだからです。

そのため、Claude Codeの機能を一つひとつ覚え、全ての手順を人間が細かく指示するだけでは、その能力を十分に活かせません。重要なのは、ツールをどのように操作するかではなく、AIエージェントがどのような環境であれば適切に判断して作業を進められるかを考えることです。 ただし、AIエージェントに全てを自由に任せれば良いわけではありません。目的や制約が曖昧なままでは、人間が期待する成果から外れたり、意図しない変更を行ったりする可能性があります。

そこで、人間には、AIエージェントが自律的に動ける余地を残しながら、目指す成果、守るべき制約、利用できる情報、確認が必要な場面を設計する役割が求められます。これは、単なるツール利用の話にとどまりません。目標や役割、権限、ルールを定め、個々の能力が発揮される環境を作るという点では、企業における組織開発やマネジメントにも通じる考え方です。本稿ではこのパラダイムシフトを出発点として、Claude Codeを効果的に活用するための環境設計について説明します。

AIコーディングとは何か

AIエージェントのコアにあるのはLLM（大規模言語モデル）です。AIエージェントはLLMが推論した結果をもとに処理を繰り返し実行するため、AIコーディングの進化はLLMの進化と切り離して考えることはできません。近年、LLMのコーディング能力は著しく向上しています。OpenAI、Anthropic、Googleなどのモデルプロバイダーが新しいモデルをリリースする際には、SWE-Bench、SWE-Bench Verified、SWE-Bench Pro、Terminal-Bench 2.0など、ソフトウェアエンジニアリング領域のベンチマーク性能が示されることが一般的になっています。実際に、各モデルのSWE-Bench Verifiedにおける解決率は2024年から2025年にかけて右肩上がりで推移しています。より高いスコアが出るとより難しいベンチマークが作られ、それをまた新しいモデルが突破していくのです。現在はこのようなサイクルが繰り返されている状況です。

LLMのコーディング能力が向上する中、AIの役割は「人間の作業を補助するコード補完」から「自律的に実装を進めるコーディングエージェント」へと移りつつあります。従来のAIのコーディング活用はIDE上で関数名や続きのコードを補完する「コード補完」が多く、ドライバーは人間であり、AIはナビゲーターとして人間の作業を補助していました。しかし、現在台頭しているのはコーディングエージェントです。コーディングエージェントは、必要な情報を適宜確認しながら次々とコードを実装していきます。ここではドライバーはAIであり、人間はナビゲーターとしてAIエージェントが進む方向を確認し、状況に応じて指示を与える立場になります。

この変化で注目したいのは、ソフトウェア開発が単一のコード生成のみで完結しない点です。ある要件に対してコードを1つ出力するだけなら、LLMの単純利用でも対応できます。ただし、実際の開発では、既存のコードベースを読んで複数のファイルを作成・編集し、関連する資料や設定を確認しながら連続した作業を進めています。これを実行するためには、環境を知覚し、LLMを推論のエンジンとしてツールを選択し、実行結果を踏まえて次の行動を決めるエージェントの仕組みが欠かせません。

コーディングエージェントが注目されている背景には、エージェント自体の自律性の向上があります。Anthropicが公表したレポートでは、攻撃者がClaude Codeを活用し、世界中の約30のターゲットへの侵入を試み、少数のケースで成功した事例が紹介されています。この事例では、活動の80〜90%をAIに実行させることができ、人間の介入が求められたのは1つのハッキング活動あたり4〜6回程度だったとされています。コーディングエージェントが単にコードを補完するだけでなく、自律的にタスクを分解し、実行し、次の行動を選択できる段階に近づいているとも考えられます。もちろん、この能力にはリスクも伴いますが、AIエージェントが高度な問題解決能力と長時間タスクに耐えうる思考能力を持ち始めていることも意味しています。

モデルが長時間のタスクに耐えられるようになるほど、そのモデルを中核に据えるコーディングエージェントも進化していきます。Claude Codeのようなプロダクトは、内部で利用するモデルの性能に依存しています。そのため、ソフトウェア本体の機能アップデートだけでなく、基盤となるモデルも進化することによってコーディングエージェントはより複雑なタスクをこなせるようになります。

ここまでの内容を踏まえると、AIコーディングとは 「コーディングエージェント（AIエージェント）を活用したソフトウェア開発手法」 と捉えていいでしょう。AIコーディングに用いられるコーディングエージェントには、Anthropic社のClaude Code、OpenAI社のCodex、Anomaly社のopencode、GitHub社のCopilotなど、さまざまな選択肢があります。現在、世界中で注目されているのは、コーディングエージェントにどのように仕事を任せ、いかに開発プロセスへ組み込んでいくかという点です。このように期待が高まっている一方で、実運用には課題もあります。

AIコーディングの課題

代表的な課題は3つあります。1つ目は「言ったものと違うものができた」です。実は、AIエージェントに作ってほしいものを正確に伝えることは簡単ではありません。2つ目は「『完了』と言われたが、コードが動かない」です。エージェントがタスクを完了したと説明しても、コードが動作しないことがあります。3つ目は「ルールを無視し、重複コードが散在する」です。あらかじめ伝えていたはずのルールが守られず、プロジェクト内に重複した実装や意図しない変更が発生することもあります。こうして見るとコーディングエージェントを実務で使うことに不安を覚えるかもしれませんが、これらをAIエージェントの限界として捉えず、前提情報、検証手段、行動制御の機構が与えられていないことによって起こる現象として理解することが大切です。

課題①「言ったものと違うものができた」

例えば「Bootstrapを使わず、モダンで洗練されたダークモードのダッシュボードを作ってほしい」と依頼したとします。この「モダン」「洗練された」「ダークモード」といった言葉には幅があります。iPhoneのような黒を基調としたUIを想定する人もいれば、ダークウェブ的な雰囲気を連想する人もいます。言葉には多義性があるため、AIエージェントは人間の期待と異なる解釈をして依頼したものとは違う成果物を出してくるのです。

課題②「『完了』と言われたが、コードが動かない」

エージェントが「タスクが完了しました。これで動作します」と説明しても、実行するとエラーが出ることがあります。また、修正を依頼すると「修正しました。これで動きます」と返ってくるものの、やはり動きません。こうしたやり取りが繰り返されることは、AIコーディングではめずらしくないのです。

課題③「ルールを無視する。重複コードが散在する」

AIエージェントは自律的にツールを選択し、ファイルを作成・編集し、コマンドを実行します。そのため、行動を制御する機構が不足していると、意図しない変更やルールから外れた実装が発生する可能性があります。ブラウザベースのAIコーディングプラットフォームであるReplitでは、AIエージェントが企業の本番データベースを削除してしまった事例が報じられています。コードフリーズの指示が出ていたにもかかわらず、AIエージェントが本番データベースに対して操作を行い、問題が発生しました。この事例が示しているのは、AIエージェントに作業を任せる際には「やってほしいこと」を伝えるだけでは不十分だということです。何を作るのかを明確化し、作ったものを自分で検証できるようにし、守るべきルールをプロンプトだけでなくルールベースでも制御します。では、なぜこのような課題が起こるのでしょうか。

なぜ、このようなことが起こるのか

AIエージェントとは、目標に向けて環境と相互作用しながらタスクをこなす知能システムです。コーディングエージェントの文脈では、この「環境」にあたるのがコードベースです。ソースコード、設定ファイル、ドキュメントなどを含むプロジェクト全体が、コーディングエージェントにとっての作業環境になります。コーディングエージェントはこの環境を知覚しながら動作します。「知覚」とは、プロジェクト内にどのようなファイルがあるのか、自分が編集したファイルがどのように変わったのか、実行結果として何が返ってきたのかを把握することです。その情報をもとにLLMが次の行動を計画して適切なツールを選択します。

Claude Codeのようなコーディングエージェントには、ファイルを読み込む、検索する、編集する、書き込む、コマンドを実行する、Web検索を行うといった複数のツールが組み込みで用意されています。ユーザーからの依頼や実行結果をもとに、LLMが使用するツールを選択して実行するとコードベースという環境が変更され、エージェントは再びその変化を知覚し、次の行動を選択していきます。つまり、コーディングエージェントとは、知覚した情報をもとにツールを選択し続けるシステムなのです。 この動作原理を前提にすると、AIコーディングで起こる3つの課題も整理しやすくなります。

課題①「言ったものと違うものができた」は、エージェントが正しく計画するための情報を与えられていない場合に起こります。エージェントが適切なツールを選択し、ユーザーの意図に沿った成果物を作るためには何を作るのか、どのような制約があるのか、既存のコードベースがどのようになっているのかといった情報が必須です。プロンプト、コードベース、これまでの会話やコンテキストが不足していると、LLMは要件に沿った実装計画を立てられず、期待とは異なる成果物を出してしまいます。

課題②「『完了』と言われたが、コードが動かない」は、エージェントに確認する手段が与えられていない場合に起こります。ファイルを読む、検索する、編集するといったツールがあっても、作成したソフトウェアが本当に動くかどうかを検証できません。Webアプリケーションであればブラウザを操作する環境やCLIツールを実行する手段、テストコードを走らせる検証フローなどが求められます。この確認手段がなければエージェントは自己検証できず、「完了」という言葉を信じることができません。

課題③「ルールを無視し、重複コードが散在する」は、エージェントの行動を制御する機構が与えられていない場合に起こります。AIエージェントは与えられたツールを選択し続けるシステムです。Bashのように任意のコマンドを実行できるツールを使える状態であれば、その権限の範囲内でさまざまな操作が可能になります。LLMの出力には揺らぎがあり、プロンプトで「これをしないでください」と伝えても、必ずしも守られるとは限りません。もしルールを逸脱した行動をAIエージェントの外側から止めるガードレールがなければ、意図しない操作が実行される可能性があります。そこで、プロンプトで注意した上で行動を制御する機構を設計します。

AIコーディングの課題は、単にエージェントの性能不足によって起こるわけではありません。多くの場合、プランニングに合致する情報、自己検証するための手段、行動を制御するための機構が与えられていないことによって起こります。AIコーディングを実務で活用するには3つの原則が重要です。「何を作るか」を定義すること、「自己検証」を仕組み化すること、そして「守るべきこと」を育てることです。

AIエージェントの3つの原則

ここまで見てきた3つの課題はAIエージェントに必要な情報や実行環境が不足していることによって起こります。AIコーディングを実務で活用するには、課題ごとに対応する原則を押さえなければなりません。

課題①「言ったものと違うものができた」では、「何を作るか」を定義することが鍵となります。AIエージェントが適切に計画を立てるためには作るもの、制約条件、期待する成果物を具体化することが望まれます。

課題②「『完了』と言われたが、コードが動かない」では、「自己検証」をできる環境を整えることが前提です。エージェント自身が作成したものを確認して適宜修正できる環境を整えることで「完了」という言葉の信頼性を高めることができます。

課題③「ルールを無視し、重複コードが散在する」では、「守るべきこと」を育てることが重要です。AIエージェントに守らせたいルールは、最初から完璧に設計できるものではありません。実際の開発や運用の中で、どの行動を許可・制限するのかを継続的に調整することが前提になります。

原則①「何を作るか」を定義する

AIエージェントに期待したとおりの成果物を作ってもらうには、人間とAIエージェントの双方が作るものを細部まで理解できる状態をつくらなければなりません。 そのために有効なのが、Claude Codeの「プランモード」です。私が開発を行う時、まずGitHub Issueに「何を実現したいのか」「どのような課題を解決したいのか」を詳細に記述します。GitHub Issueは、ソースコードを管理するGitHub上でやりたいことやバグ、課題を管理するための仕組みです。

その上でClaude CodeにIssueの内容を読み込ませ、プランモードで「この内容を実装するにはどうすればいいか」を具体的に検討させます。実装に情報が不足していると、Claude Codeが質問を返してくれます。この対話を通じて要件を精緻化し、最終的に人間もClaude Codeも実装イメージを持てる状態にしてから開発を開始します。この段取りを踏むと、AIエージェントに対して期待する成果物を伝えやすくなります。

Claude Codeだけでなく、OpenAI社のCodexにもプランニングを支援する機能があります。Codexでは、設定ファイルにcollaboration_modesを追加すると対話を通じたプランニングを行えるようになります。このような機能が用意されていること自体、AIコーディングにおいてプランニングがいかに重要であるかを示しています。さらに実践的な使い方として、Claude Codeが作成したプランをCodexにレビューさせる方法も有効です。Claude Codeは大局的な構成を捉えやすい反面、忖度しやすく、細部の詰めが甘くなることがあります。Codexは細かな矛盾や抜け漏れに気づきやすい傾向があります。これは利用時の体感を含む話ですが、異なるモデルやエージェントの特性を組み合わせることで、プランニングの品質を高められます。

最近では、AI-DLCやスペック駆動開発といった方法論も登場しています。AI-DLCはAIと協働しながら詳細な作業計画を作成し、開発からデプロイまでの一貫したライフサイクルを定義する考え方です。Claude CodeやCodexを使った開発ワークフローにも活用できます。スペック駆動開発は仕様書を構造的に作成し、その仕様書をもとにAIエージェントを動かす開発手法です。ドキュメントを唯一の情報源、すなわちSingle Source of Truthとして位置づけ、人間はドキュメントの整備に集中し、AIはその仕様に沿って実装を進めます。この方法を取ることで、どのプランが不十分だったのか、どの仕様に抜け漏れがあったのかを体系的に振り返りやすくなります。

ただし、計画を明確化する際に注意すべき点があります。それは、コンテキストロット（Context Rot）です。AIエージェントに多くの情報を与えれば与えるほど、精度が上がるように思えるかもしれません。しかし、実際には入力が長くなるほどモデルの性能が低下することがあります。 Chroma社のレポートでも、入力長が伸びるほど主要なLLMの性能が低下する傾向が指摘されています。そのため、必要な情報を整理し、できるだけ少ないトークンで効果的に渡します。会話が長くなり、出力が間延びしてきた場合は一度セッションを区切り、整理された情報を改めて渡すことも有効です。

人間も、突然20冊の本を渡されて「これを全部読んで仕事をしてください」と言われたら混乱します。AIエージェントも同じで、整理されていない大量の情報よりも、構造化された情報を渡したほうが精度の高い仕事に繋がります。

原則②「自己検証」を仕組み化する

2つ目の原則は「自己検証」を仕組み化することです。この原則の本質は、自分で作ったものは、自分で動作確認してもらうことにあります。 AIエージェントがコードを書いたとしても、そのコードが問題なく動作するかどうかを確認できなければ「完了」とは言えません。そのため、AIエージェントが自分で成果物を検証できる環境が求められます。Webアプリケーションであれば、MCPやCLIツールを経由してブラウザを操作させる方法があります。例えば、Chrome DevTools MCPを使うとClaude Codeがブラウザを起動し、画面上で入力や操作を行いながら動作確認できるようになります。

人間がブラウザを開いて確認していた作業をAIエージェント自身に実行させるイメージです。画面が正しく表示されるか、テキストフィールドに文字を入力した時に期待どおりの挙動になるか、タスクを追加した時に状態が更新されるか、です。こうした確認をAIエージェントが行えるようになるとコードを書くところで止まらず、実行結果を踏まえて修正するループを回せるようになります。また、Webアプリケーションに限らず、テストコードやCLIツールを直接実行して確認させることも有効です。AIエージェントに「確認してください」と伝えるだけでなく、その手段をエージェントが使える形で用意しておくことがポイントです。

しかし、自己検証のための環境自体をAIエージェントに作らせればいいとは限りません。セットアップもAIエージェントに任せたくなりますが、ソフトウェア開発環境の構築は複雑であり、AIエージェントが扱える権限や情報の外側にある要素も多く含まれます。そのため、環境構築はAIエージェントが苦手とする領域の一つです。SetupBenchの研究でも、ソフトウェア開発環境の構築におけるAIエージェントの能力には課題があることが示されています。これはAIエージェントの使い方が悪いというよりも、現時点ではAIの性能がその領域に追いついていないからです。

自己検証を成立させるには、MCPやCLIによってエージェントが確認できる手段を用意し、その結果をもとに修正するループを設計します。ただし、その仕組み自体は人間の手で整備するほうが現実的です。AIエージェントに自律的に動いてもらうためにはまず、人間が自己検証できる環境を設定します。

原則③「守るべきこと」を育てる

3つ目の原則は「守るべきこと」を育てることです。「守るべきこと」とは、AIエージェントに対してどのような作業を許可し、どのような作業を禁止するのかを明確にすることです。特に、AIエージェントに守ってほしい領域の中身を最初から細かく定義しきることではなく 「ここから外に出てはいけない」というOBゾーンを定めること です。プロジェクトの調整や組織固有のルールがある場合、AIエージェントにはその範囲内で作業してほしい一方で、本番データベースを破壊する可能性のある操作やプロジェクト全体を削除するコマンドは、完全にOBゾーンとして禁止すべきです。

この外枠を定義し、運用しながら少しずつ精緻化することが「守るべきことを育てる」という考え方です。Claude Codeでは、ツールを実行する前後などのタイミングで、特定の処理を差し込むHooksという機能があります。Hooksを使用すると、ルールベースによる禁止処理の定義や、ファイルに対するlintの実行などが可能になります。例えば、AIエージェントがBashツールを選択し、ルートディレクトリ配下のファイルを全て削除する、危険なコマンドを実行しようとしたとします。このような状況で外側から止める仕組みがなければ、そのコマンドはエージェントに与えられた権限の範囲で実行されてしまう恐れがあります。

そこで、ツール実行の直前にPreTool Hookを設定し、危険なコマンドを検知した時点で実行を止めるようにします。プロンプトで「この操作はしないでください」と伝え、実行前にプログラムとして禁止します。これが、ルールベースで守るということです。LLMのプロンプト理解性能が向上しているため「プロンプトで明示すれば守ってくれる」と考える人もいるかもしれません。確かに、ある程度は守られることもありますが、常にそうだとは保証されていません。特に、本番データベースやクラウド環境、社内システムなど、誤操作が損害に繋がる領域では「守られるかもしれない」に依存するのは危険です。確実に守らせたいルールは、プロンプトではなく、フックのような制御機構によって強制します。

エージェントに作業の進め方を伝える用途であれば、エージェントスキルが有効です。エージェントスキルは「どのような状況で、どのように作業を進めればいいか」をマークダウンなどで定義し、場面に応じてエージェントに渡す機能です。特定のクラウドサービスを操作する際の手順や特定のコマンドの使い方をスキルとして定義することで、エージェントはその作業を進めやすくなります。

ただし、エージェントスキルはあくまでプロンプト依存の機能です。エージェントが自己判断で参照したり、ユーザーの指示によって呼び出されたりするものであり、必ず守られることを保証するものではありません。作業方法を伝えるならエージェントスキル、絶対に止めたい操作を制御するならフックというように役割を分けて考えます。

関連情報

ジェネラティブエージェンツでは、AIコーディングやAIエージェントの開発・導入に関する研修、講座、情報発信を行っています。AIコーディングを基礎から体系的に学びたい方は『実践Claude Code入門―現場で活用するためのAIコーディングの思考法』や企業向け研修「AIコーディング実践講座」も併せてご覧ください。