はじめに
AIに自然言語で指示し、AIエージェントに処理を作らせる。こう説明すると、最近では「バイブコーディングですね」と分類されることがあります。
しかし、少し違和感があります。
筆者が最近行った実験では、プログラムのコードを一行も書いていません。どの言語を使うか、どんなライブラリを使うか、どうデータを加工するかといった実装方法についても、かなりの部分をAI側に任せました。
一方で、何を調べたいのか、どのようなデータなら根拠になるのか、AIが間違った方向へ進んでいないか、最終結果をどこまで信用してよいかについては、人間側で判断しています。
つまり、人間が持っていたのは「実装方法」ではなく「意図」でした。
そこで本稿では、自分の意図をAIによって実装する開発スタイルを「意装開発（いそうかいはつ）」と呼ぶことを提案します。これは既存の標準用語ではなく、筆者による提案語です。
意装開発 ＝ 人間の「意図」 × AIによる「実装」
重要なのは、単にAIにコードを書かせることではありません。
AIエージェントが高度化した結果、人間が「How」を直接記述しなくても、「Why」「What」「どこまでできたら成功か」を渡すことで、実装そのものを組み立てられるようになってきました。
本稿では、実際に行った「正引き」という言葉の読み方を調査する実験を題材として、意装開発とは何か、バイブコーディングやSpec-Driven Developmentとは何が違うのか、そしてAIエージェント時代に人間が担うべき仕事は何なのかを考えます。
1. なぜ「バイブコーディング」では足りなかったのか
「Vibe Coding」という言葉は、Andrej Karpathy氏が2025年2月に提示した表現から広まりました。元々の説明では、LLMに指示して結果を動かしながら修正し、コードそのものへの関与をかなり薄くする、実験的で感覚的な開発スタイルが描かれています。Karpathy氏自身も後に、専門的に扱うAI支援開発とVibe Codingを区別しています。1
したがって、「自然言語でAIにコードを書かせる行為」をすべてVibe Codingと呼ぶのは、元々の意味よりかなり広い使い方になります。
現在のAIコーディングエージェントは、単なるコード補完からさらに先へ進んでいます。OpenAIのCodexはリポジトリを読み、ファイルを編集し、コマンドやテストを実行できます。現在のChatGPT版Codexでは、複数エージェントを並行稼働させるワークフローも提供されています。2 AnthropicのClaude Codeもコードベースを探索し、ファイル編集、テスト、Git操作などを自然言語による指示から実行できます。3
ここまで来ると、人間の作業を「コーディング」と呼ぶべきなのかが怪しくなってきます。
例えば、筆者が「この条件を満たすデータを集め、分類し、傾向を分析してほしい」と依頼したとします。その裏側でAIがPythonを書いたとしても、シェルコマンドを実行したとしても、データベースを作ったとしても、人間側から見ればそれらは実装詳細です。
人間が設計しているのは、コードではなく「何を実現したいか」です。
そこで、既存の概念を次のように整理すると分かりやすくなります。
| 開発スタイル | 人間が主に持つもの | AIが担う範囲 | 特徴 |
|---|---|---|---|
| 従来型開発 | Why / What / How | 補助 | 人間が実装方法まで設計する |
| AI支援コーディング | Why / What / How | コード生成・補完 | 人間が実装を理解しながらAIを使う |
| Vibe Coding | 方向性・体験 | 実装の大部分 | 動かしながら感覚的に修正する |
| Spec-Driven Development | 仕様 | 計画・タスク・実装 | 仕様を中心成果物としてコードを生成する |
| 意装開発 | Why / What / 制約 / 評価基準 | Howの設計と実行 | 人間の意図をAIが実装可能な形へ変換する |
意装開発はVibe Codingの対義語でも、Spec-Driven Developmentの代替でもありません。
むしろ、人間とAIの責任分界をどこに置くかを表す言葉です。
2. 「意装開発」とは何か
本稿で提案する意装開発を、もう少し厳密に定義します。
意装開発とは、人間が目的・制約・判断基準を保持し、それを自然言語などでAIへ伝え、AIが具体的な設計・実装・処理を組み立て、人間が結果を意図に照らして検証する開発スタイルです。
構造としては次のようになります。
人間
│
│ Why
│ What
│ 制約
│ 評価基準
▼
┌───────────┐
│ 意図 │
└────┬──────┘
│ 自然言語
▼
┌───────────────┐
│ AIエージェント │
└────┬──────────┘
│
│ 設計
│ コード
│ データ加工
│ 調査
│ テスト
▼
┌───────────┐
│ 成果物 │
└────┬──────┘
│
│ 検証
▼
人間
│
└── 意図との差分を再指示
ここで重要なのは、「コードを書かないこと」が意装開発の条件ではないという点です。
必要なら人間がコードを書いても構いません。
本質的な違いは、人間が実装手順をすべて決めなくてもよいことです。
AIへ「PythonでCSVを読み、このライブラリを使い、このループを書いて」と命令するのであれば、従来型開発を自然言語で記述しているだけとも言えます。
一方で、「この仮説を検証できるデータセットを作り、妥当性を確認できる方法を考えて実行してほしい」と渡し、AI自身が処理方法を組み立てるなら、人間は実装レイヤーから一段上へ移動しています。
この違いを整理すると、意装開発に必要なのは次の4点です。
- 人間が達成したい目的を持っている
- AIに任せてよい範囲と制約が定義されている
- AIが実装方法をある程度自律的に選択できる
- 人間が成果を判定できる評価基準を持っている
単発でChatGPTに質問して答えを得るだけなら、意装開発とは呼びません。
AIとの対話を通じて、何らかの処理、仕組み、データ、システム、分析工程などを構築していくところまでが「開発」です。
この構造は、実際のAIエージェント利用にも表れ始めています。Anthropicが2026年6月に公表したClaude Code約40万セッション、約23.5万人を対象とする分析では、典型的なセッションにおいて、人間が計画上の判断を多く担当し、Claudeが実行上の判断を多く担当する傾向が確認されています。また、利用者が持つ対象分野の専門性が高いほど、成功しやすい傾向も報告されています。4
これは意装開発の考え方とかなり近い構造です。
AIが賢くなるほど、人間が不要になるのではありません。
人間の仕事が「作業」から「意図と判断」へ移っていると見る方が実態に近いのではないでしょうか。
3. 実例：「正引き」の読み方をコードを書かずに調べる
意装開発を考えるきっかけになった実例を紹介します。
発端は「正引き」という言葉でした。
「せいひき」なのか「せいびき」なのかを確認しようとすると、Web検索では両方が見つかります。一方、一般的な辞書では、そのものずばりの語が十分に見つかりません。
普通にAIへ尋ねれば、辞書や検索結果を調べ、もっともらしい回答を返して終わるでしょう。
しかし、今回知りたかったのは辞書に答えがあるかどうかではありませんでした。
筆者の意図は、日本語に存在する「○○引き」という語を大量に集めれば、「引き」が「ひき」「びき」「ぴき」のどれになるのか、何らかの傾向をデータから推定できるのではないかというものでした。
そこでAIへ調査を任せました。
ところが、最初の試行ではAIが辞書から「○○引き」を収集し、一覧を作り始めました。
これは一見すると正しそうですが、今回の目的からすると失敗です。
なぜなら、辞書に「正引き」が十分掲載されていないからこそ、辞書に依存しない方法で傾向を探そうとしているためです。
ここに、意装開発における人間の重要な役割があります。
AIが正しい作業をしているかではなく、自分の意図に沿った作業をしているかを判断する必要があります。
そこで方針を修正しました。
文字の組み合わせから約50万パターンを生成し、その中からAIに「日本語の単語として成立しそうなもの」を絞らせました。200件を超える候補が得られたため、そこから実際の使用例、辞書、Web上の用例などを確認し、「ひき」「びき」「ぴき」の読み方や語の特徴を整理する方向へ進めました。
問題設定
↓
「正引き」の読みを辞書以外から推定できないか
↓
約50万パターンを生成
↓
AIが単語らしい候補を抽出
↓
200件超まで絞り込み
↓
辞書・Web・用例で実在性を確認
↓
ひき / びき / ぴき を分類
↓
語形・音韻・意味などの特徴を整理
↓
傾向から「正引き」を推定
この一連の作業で、筆者自身はプログラムを書いていません。
コード生成、文字列処理、候補抽出、データ整理などの具体的な実装は、チャットとAIエージェントに自然言語で指示しています。
だからといって、AIへ丸投げしたわけでもありません。
人間側では、
- 何を証明したいのか
- 辞書だけではなぜ不足するのか
- AIの候補抽出を事実と扱ってよいか
- Web上に存在することと日本語として妥当であることをどう区別するか
- どの時点で仮説を修正すべきか
といった判断を続けています。
ここに意装開発の特徴があります。
コードを書いた人が開発者なのではなく、「何を作るべきか」を保持し続けた人が開発を主導するという構造です。
また、AIが抽出した200件超の候補は、それ自体が正解ではありません。「単語らしく見える」というAIの推定にすぎないため、別の情報源を使った再検証が必要です。
AIによって作業速度は上げられても、根拠まで自動的に正しくなるわけではありません。
4. 意装開発では「プロンプト」より意図を管理する
意装開発を実践してみると、難しいのはプロンプトを書くことではありません。
難しいのは、長い作業の途中でもAIに最初の意図を維持させることです。
生成AIを使っていると、以前指定した条件が十分反映されなかったり、別の指示と混ざったり、作業の一部が抜けたりすることがあります。
これを日常語では「AIが忘れた」と表現したくなりますが、厳密には人間の記憶と同じ現象ではありません。長いコンテキストの中で情報の重要度が下がる、コンテキストが圧縮される、エージェントが過去の制約を適切に参照できない、といった複数の要因があります。
したがって、意装開発では「一度完璧なプロンプトを書く」より、意図を外部化して保持することが重要になります。
筆者なら、少なくとも次の項目を最初に固定します。
【目的】
最終的に何を実現したいか
【背景】
なぜこの作業を行うのか
【やらないこと】
今回の目的から外れる処理
【制約】
利用可能なデータ、環境、期間、権限など
【評価基準】
何が確認できれば成功と判断するか
【根拠】
どの情報源を優先するか
【途中確認】
どの段階で人間へ確認を戻すか
【成果物】
最終的に残すファイル、データ、レポートなど
これをプロジェクトの仕様書、README、AGENTS.mdなど、AIエージェントが継続して参照できる場所へ置いておけば、チャットの履歴だけに依存するより意図を維持しやすくなります。
GitHubのSpec Kitが提唱するSpec-Driven Developmentでも、仕様を中心成果物として扱い、Spec → Plan → Tasks → Implementという段階を通してAIへコンテキストを渡します。またGitHub自身が「whatをhowより先に定義するIntent-driven development」を中核原則として挙げています。5
この点で、意装開発とSpec-Driven Developmentは対立しません。
むしろ、
意装開発
└─ 人間とAIの役割分担を示す考え方
Spec-Driven Development
└─ その意図を仕様として管理する具体的な開発プロセス
と捉えることができます。
本番システムのように品質要求が高い場合には、意装開発をSpec-Driven Development、テスト駆動、コードレビュー、CI/CDなどと組み合わせた方が安全です。
意装開発だから、コードを確認しなくてよいわけではありません。
重要なのは、人間がコードを書くかどうかと、人間が品質に責任を持つかどうかを混同しないことです。
5. AIに「How」を渡すほど、人間には判断力が必要になる
意装開発には大きなメリットがあります。
これまでなら「やりたいことはあるが実装方法が分からない」で止まっていた人でも、AIエージェントを介することで試行できる範囲が広がります。
エンジニアでなくてもデータ処理を作れるかもしれません。プログラミング言語を知らなくても小さな業務ツールを作れるかもしれません。未知の分野でも、AIと調査しながらPoCまで持っていける可能性があります。
一方で、大きな落とし穴もあります。
| リスク | 何が起きるか | 対策 |
|---|---|---|
| 意図のドリフト | 作業は正しいが目的から外れる | 目的・非目的・評価基準を外部化する |
| ハルシネーション | 存在しない仕様やデータを前提にする | 一次資料と実データで再検証する |
| ブラックボックス化 | 作った本人が仕組みを説明できない | テスト、ログ、設計書、差分を残す |
| AIの過剰実行 | 意図以上の変更や操作を行う | 権限分離、承認ポイント、Sandboxを使う |
| 再現不能 | 同じ指示でも結果が変わる | 仕様、入力、モデル、成果物を保存する |
| 情報漏えい | 秘密情報を外部AIへ渡す | 組織の利用ルールとデータ分類に従う |
特に本番環境では、AIエージェントにどの権限を与えるかが重要になります。OpenAIも、Codexの組織利用では技術的境界、承認が必要な操作、接続可能なシステム、操作履歴を把握するためのテレメトリなどを重要な統制要素として挙げています。6
業務で利用する場合には、NDA対象情報、個人情報、認証情報、顧客データ、非公開ソースコードなどを、組織が許可していないAI環境へ入力してはいけません。
そして、もう一つ重要なのが専門性です。
AIがHowを担当するなら、初心者でも専門家と同じ結果を出せるように見えるかもしれません。
しかし、先ほどのClaude Codeの調査では、利用者のドメイン専門性が高いほど成功率も高くなる傾向が報告されています。4
これは当然とも言えます。
AIが高速で実装してくれるほど、人間は、
- その問題を解く価値があるか
- 前提条件は正しいか
- 出力に違和感がないか
- どこを再検証すべきか
- 何をAIに任せてはいけないか
を短時間で判断しなければなりません。
つまり、AIによって専門知識の価値が消えるのではなく、専門知識をコードへ翻訳する作業が減り、専門知識そのものを判断に使う割合が増える可能性があります。
意装開発で重要なのは、プロンプト職人になることではありません。
自分が何をしたいのかを説明でき、出てきた結果の良し悪しを判断できることです。
おわりに
本稿では、「自分の意図をAIによって実装する」という開発スタイルを「意装開発」と名付けました。
従来
人間が考える
↓
人間が設計する
↓
人間がコードを書く
↓
コンピューターが実行する
これがAIエージェントによって、次のように変わり始めています。
意装開発
人間が考える
↓
人間が意図・制約・評価基準を示す
↓
AIが設計・実装する
↓
AIが実行・検証する
↓
人間が判断する
筆者が「正引き」の調査で行ったのも、この形でした。
約50万パターンの生成方法も、その処理コードも、人間側では書いていません。
しかし、「辞書から一覧を作る」というAIの最初の方針が目的と違うことは、人間が判断しました。
ここが重要です。
AIエージェント時代に人間から実装作業が減ったとしても、意図までAIへ丸投げするわけではありません。
むしろ、実装が速くなるほど、
何を作るのか。なぜ作るのか。何をもって正しいとするのか。
という上流の判断が重要になります。
Vibe Codingが「コードを意識しなくても作れる」という変化を象徴した言葉だとすれば、意装開発はその先で、コードではなく意図を開発の起点にすることを明示する言葉として使えないかと考えています。
もちろん「意装開発」は、現時点では筆者が提案している造語にすぎません。
ただ、自然言語でAIエージェントへ仕事を渡し、人間が成果を判断する働き方が一般化していけば、「これはコーディングなのか」という分類よりも、「人間は何を設計し、AIは何を実装したのか」という責任分界を表す言葉の方が重要になっていくはずです。
次に試すべきなのは、意装開発を「コードを書かなかった開発事例」として終わらせず、目的、制約、検証条件、AIへの委譲範囲をテンプレート化し、別のテーマでも同じ工程を再現できるか検証することです。
再現できるのであれば、意装開発は単なる造語から、AIエージェントを使いこなすための開発方法論へ進められます。
参考
-
Andrej Karpathy氏が2025年2月に提示したVibe Codingの原文、および同氏が後にprofessional AI-assisted codingとvibe codeを区別した投稿。原X投稿は取得制限があるため、投稿情報を収録した資料でも照合しています。 (Agile Japan) ↩
-
OpenAI「Codex」。Codexによる機能実装、リファクタリング、移行、複数エージェントの並行処理などの公式説明。 (OpenAI) ↩
-
Anthropic「Claude Code 概要」。コードベース探索、ファイル編集、テスト、Git操作などのエージェント機能に関する公式資料。 (Claude Platform Docs) ↩
-
Anthropic, “Agentic coding and persistent returns to expertise”, 2026年6月16日。2025年10月から2026年4月までの約40万Claude Codeセッション、約23.5万人を対象とした分析。人間が計画上の判断を、Claudeが実行上の判断を多く担う傾向や、専門性と成功率の関係を報告しています。 (Anthropic) ↩ ↩2
-
GitHub「Spec Kit / Spec-Driven Development」。仕様を中心にSpec → Plan → Tasks → Implementを進め、whatをhowより先に定義するIntent-driven developmentを説明しています。 (GitHub) ↩
-
OpenAI「Running Codex safely at OpenAI」。AIコーディングエージェントに対する技術的境界、承認、接続先、テレメトリなどの統制についての公式資料。 (OpenAI) ↩