Introduction
近年、ClaudeCodeやGeminiCLIをはじめとするCLIのエージェント型AIが注目を集めています。
VibeCodingなる概念の登場により、「非エンジニアでもプログラミング知識なしでソフトウェア開発が可能になる！」と一部で言われています。
その界隈では「プログラマーはもはや不要！パラダイムシフトに乗り遅れるな！」といった極端な意見も聞かれます。
しかし、私はこうした誇張された意見に対しては常に懐疑的です。
- 非エンジニアでもプログラミング知識なしにソフトウェアを量産できる
- このAI時代のパラダイムシフトに乗り遅れると、もはや生き残れない
- AIを使いこなせない者は時代遅れだ
- プログラミングを学ぶ時代は終わり、AIを使って速やかにアイデアを量産すべきだ
このような極端な主張をする人々は、自身の情報商材や教育プランといった商品を売り込みたいだけである可能性があり、注意が必要です。
これは情報商材業界の人々が昔からよく使う、「危機を煽って人間の行動を誘導しようとするマーケティング手法」です。
私は、このような認知バイアスを逆手に取ったマーケティング手法をあまり好みません。
情報を知らない人を騙して自分だけが儲かろうとするビジネス思考には嫌悪感しかありません。
彼らがいつまでも懲りずに、手を変え品を変えながら昔と同じやり方を続けられるのは、ある意味で感心します。
しかし、こうした手法に実際に騙される人がいるのも事実です。注意喚起の意味も込めて、実際にエージェント型AIを使ってみた率直な感想と実装例をまとめたいと思います。
本当にエージェント型AIがあれば、プログラミングスキルは不要なのか
ここでいうプログラミングスキルとはソフトウェア開発における企画、要件定義、設計、実装、テスト、デプロイ、運用、改修を指します。
はたして、自然言語のみで素人がソフトウェア開発できるのでしょうか。
自然言語縛りでエージェント型AIを使用してソフトを作った感想
結論から述べると、私の言語能力では自然言語のみで全てのコーディングをエージェント型AIに任せて、満足のいく品質のソフトウェアを開発することはできませんでした。
したがって、非エンジニアやプログラミング知識が全くない人でも実用に耐えゆるソフトウェアを量産できる時代が来たという意見には懐疑的です。
では、現場のプログラマーの方々が、エージェント型AIを使用することで、生産性は飛躍的に向上するのは事実でしょうか．
残念ながら、巷で言われているような2、3倍になるとの期待しましたが，体感としては2、3割程度の向上という印象です。
チャット型AIに複数のソースコードファイルを読み込ませる際の大量のコピー＆ペースト作業が不要になった程度でしょうか。
正しく評価するならば、エージェント型AIを用いて（プロンプト作成、AIによる生成、コードレビューなどの確認作業を含め）成果物を作成した時間と、人が同じ成果物を作成した時間を定量的に比較すべきですが、個人での検証は困難であるため、あくまで私個人の感想であることをご容赦ください。
ここからは、ClaudeCodeやGeminiCLIなどを使用してみた感想を列記します。
- 大きなタスクを任せると意図しないコードが生成され、コードレビューや手戻りが発生するため、効率的とは言えません。
- 逆に細かいタスクに分ければ精度は上がりますが、その分プロンプトを書く量が増大します。
- 複雑なアルゴリズムを作成させようとすると、プロンプトの量が増え、人が直接コードを書いた方が早い場合が多いです。
- 対話で修正依頼を繰り返しても最終的に解決できなかった場合、その損失は小さくありません（安物買いの銭失いに近い感覚です）。
- AIはアウトプットが速いため、AIが生成した大量のコードを読み解くのは非常に疲れます（脳内のコンテキストスイッチが増加するためです）。
- 今まで単純作業で面倒だと感じていたコーディング作業中こそ、脳を休め、拡散的思考をしていたことに気づかされました。
- 自分で理解してコードを書くことで、後になって何が悪い設計で何が良い設計だったのかを判断できるようになっていたことに気づきました．
- 自己のソフトウェア開発の理解という観点では、AIにコーディングを頼りすぎることは成長の阻害要因となり得ると感じました．
AIの得意・不得意を考慮した上で、時間をかけずに成果物を得る（生産性を上げる）方法を確立するのは、思ったよりも難しいと感じました。
エージェント型AIでも人によるコントロールは止められないのか
AIに自走させすぎると、下記のように後戻りできないほどコード全体が崩壊し、プロジェクトを破棄せざるを得なくなることが頻繁に発生しました。
そのため、コードレビューや実装のコントロールを徹底する必要があると痛感しました。
そういった意味では、最近のモダンな開発環境は複雑で抽象度が高すぎるのかもしれません（Next。js + TypeScript + Dockerなど複数の技術スタックを組み合わせる）。
モダンな開発スタイルを理解できず、なかかな移行できない人が実際にいることを考えると、認知的負荷が高すぎるのかもしれません。
よってモダンな開発スタイル複雑すぎて、AIにとっても不向きなのかもしれません。
小まとめ
モデルもツールも日々進化していくため、現在のエージェント型AIのベストプラクティス探索をどの程度で終えるべきかという「最終停止問題」が付きまといます。
よって、現時点では一旦探索作業を中断し、次のステップへ進もうと思います。
私が2025年6月末時点での機能で考えたエージェント型AIを活用して、自然言語のみで駆動するシステムはどうやって設計すればいいかについて考察します。
エージェント型AIを使って自然言語のみで駆動できるアーキテクチャはどうやって設計すればいいのか
エージェント型AIで出来ることを考慮したうえで、どのように自然言語のみで開発できる環境を構築すればよいのでしょうか。
開発システム自体のアーキテクチャを考えたいと思います。
エージェント型AIとチャット型AIに違いとは
使用した感想としては、LLMのモデル自体の精度はチャット型AIと大差ないという印象でした。（高額なモデルは試していないため、私のような個人が利用できる範囲に限定される話かもしれませんが、）
結局のところ、エージェント型であろうと、与えられたコンテキスト内の中央値しか出力できないという点は変わらない、というのが私の感想です。
では、エージェント型がチャット型と異なり優れている点は何でしょうか。
それは、主にファイルI/Oやコマンド実行ができる点だと考えます。チャット型では不可能だった様々な処理が考えられます。
- プロンプトをテキストファイルとして構造化・定型化することで、コンテキストの再利用性が高まります。
- 複数のテキストファイルを組み合わせることで、複雑なコンテキストを複数パターンで与えることが可能になります。
- AIのアウトプットを、次のタスクを指示するプロンプトファイルにすれば、そのアウトプットをもとにタスクを実行でき、非同期処理が可能になります。
- プロンプトをテキストファイルとして残すことで、Gitなどのバージョン管理システムで管理できます。
ClaudeCodeやGeminiCLIの入門を謳う商材の多くは、直接ターミナルにプロンプトを打ち込んだり、ファイルに記述して読み込ませたりする手法を推奨し、「あとは指示するだけ」と説明しています。
しかし、このような方法では再利用性が低く、途中の軌道修正が困難であったり、会話が続くことで（コンテキストが増えることで）AIが以前の指示を忘れてしまうなどの問題が発生する可能性が高いです。
この「ファイルを扱える」という特徴を活かし、エージェント型AIのタスクを適切に分割することで、精度の高いアウトプットを効率的に得られると考えています。
次に、私たちが普段行っている仕事を抽象化した上で、エージェント型AIを効率的に使用するためのシステムアーキテクチャを検討します。
私たちはどうやって仕事をしているのか
まず、私たちの仕事内容を抽象化して考えてみます。この抽象化作業にはAIを活用します。
まず、頭の中のイメージを素早くコードに起こします。
class Todo:
"""タスクの要素。作業最小単位"""
class IProcess:
"""処理順番"""
array: list[T]
class TodoProcess(IProcess):
"""todoの処理順番"""
todos: list[Todo]
class Task:
"""仕事をなすべき構成要素。達成すべき課題。"""
processes : list[TodoProcess]
class TaskProcess(IProcess):
"""taskの処理順番"""
tasks: list[Task]
class Work:
"""valueを生む仕事。人の欲求によりエネルギー不均衡が生まれ、エントロピーが拡散する際に仕事になるイメージ。"""
processes : list[TaskProcess]
class Value:
"""人が主観的に価値があると思うもの。欲求といってもいい。エネルギー不均衡を生むイメージ"""
works: list[Work]
上記の継承ツリーをAIを使ってクラス図にします。一発では細部が間違っていることが多いため、人がチェックして、修正すれば完成です。
私たちの仕事はいくつかのノード（タスク）に分解され、それぞれのノードのタスクの中にさらに細かいノードが存在します。ノード間に依存関係がある場合、前のノードが完了しなければ次のノードは実行できません。この関係性をプロセスとして定義できます。
具体的にアーキテクチャはどうすればいいのか
抽象化の結果、タスクをどのように言語化し、テキスト形式でエージェント型AIに与えるかを考えます。頭の中の定義プロセスを言語化してみます。
- 私たちが仕事を行う上では何らかの目的があると考えます。
- 目的によって生まれる価値があると仮定します。
- この価値を生み出すためのミッションが定義されます。
- このミッションに基づいて、各個人が何を行うべきかをタスクとして考えます。
- この際の最小タスクを言語化したものを「チケット」とします。
- チケットをAIエージェントにコンテキストとして与えます。
- チケットを作成するチケットを作成し、そのチケットを処理することも可能です。
- エージェントは与えられたコンテキストの範囲内でTODOを検討し、実行します。
- アウトプットは非同期で次々と完成します。
- 人間はアウトプットを確認します。
それを図化します。
今回検討したシステムアーキテクチャを用いた開発を、仮にチケットAI駆動開発（仮）と命名します。
これはウォーターフォールモデルの各工程で作ったドキュメントをバケツリレーのように次の工程へパスしてく様子を彷彿とさせます。
アジャイル開発やDDDなど、様々な開発手法が提唱されてきましたが、シンプルなウォーターフォールモデルに原点回帰しているように感じます。
エージェント型AIを使ったドキュメント作成システムを実際に作ってみる
エージェントAI(GeminiCLI、 ClaudeCode)を使い、自然言語の指示のみで、ドキュメントを作成、修正できるシステムを作ってみました。
チケットAI駆動開発（仮）を基に、ドキュメント作成システムの具体例を検討しました。
エージェント型AIを使ってブログ記事や要件書、Web調査レポートなどのドキュメントを作成するシステムです。
実際の中身は下記のリポジトリを参照いただければと思います。
git等が使えない人でも<> Codeのボタンからzipとしてdownloadできます。
GeminiCLI、 ClaudeCodeの導入の方法はほかの方に譲ります。
エージェント型AIを使った自然言語のみで開発できるシステムを制作してみた感想と今後について
開発してみた感想
普通にコーディングするソフトウェアの開発プロジェクト（従来の開発）のように、自然言語のみでエージェント型AIが処理するアーキテクチャを考えてみました。
やっていることは、プログラミング言語ではなく自然言語で処理をつないでいく感覚だったので、同じでした。
構想、要件、設計、実装ぐらいまでは同じ要領でしたが、テスト以降がどうすればいいか分かりませんでした。
従来の開発のように自動手テストを組むといったことが私の技術では難しく、AIが出してくるアウトプットを現状では人力で確認する必要があり効率的なのか謎でした。
従来の開発ではどこかミスがあれば、エラーが（エラーになるように設計できる）でるため、トレースみれば問題個所の特定するのが容易です。それに比べて、自然言語のみで処理を記述した場合、エラーは発生しません。結果をみて、思っていた処理と違ったら、どこのプロンプトが悪いのか目で原因を探さないといけません。
従来の開発の場合、エンジニアがコーディング割く作業時間は全体の2，3割でほぼ、コミュニケーションや問題解決などにリソースを使っている気がします。
この、コーディング時間がほぼ0になったとしても全体の生産性は2，3割しか上昇しないのではないか。というのが私の仮説です。
プログラマーが不要を訴えるひとが考える job description と、現場のプログラマーの job description ではギャップがあると感じます。
私の中ではプログラマーはソフトウェアエンジニアと同等と考えています。
現場の人間は「プログラミング言語が書けることはソフトウェアエンジニアにとって必要条件であるが十分条件でない」と考えているのに対し、
プログラマーは不要を訴える人にとっては「十分条件である」という認識だと思います。
運用してみた感想
このシステムを使用することで、後で調べようと思いつつも面倒で敬遠していた事柄でも、思いつきでレポートとして出力できるようになりました。
正直なところ、レポートの生成速度が速すぎて読むのが追いつかないほどです。
- 一般的な知識に関する内容であれば、多少の手直しとファクトチェックで公開可能なレベルの記事に仕上がると思います（すでにネット上に同様の知見があるため、その記事自体に大きな価値はないかもしれませんが）。
- 技術的なレポートを作成させると、内容がひどいことが多いです（LLMが理解しているのは単なるモデルであり、その限界を痛感させられます）。
- 自分にとって知識のないジャンルでも、一般的に使用される単語を拾い上げてくれるという意味では重宝しています。
システムの評価をどうするのか問題
記事作成において、確かにアウトプットは量産できますが、効率的に価値を生み出せているかについては疑問が残ります。
前述の通り、正確に定量的に評価するのは非常に難しいです。
- 再現性: 同じプロンプトで同じ結果が得られるか
- 正確性: 期待通りの結果が得られるか
- 処理速度: タスク実行にかかる時間
- エージェントAIの使用料
- コンテキスト量（トークン数）: プロンプトの量
- チェック時間
など、様々な指標を考慮する必要があると考えます。システムの運用は、それを使う人に大きく依存するでしょう。実験条件によって結果が変わることもあります。
したがって重要なのは、どのような条件と方法で実験を行い、どのような結果を得たかを記録し、蓄積していくことです。科学的なアプローチは時間がかかりますが、間違いを認め、是正できるという意味で優れています。
いつか、AIを活用したシステムのベンチマーク方法が確立されることを願っています。最後に、他力本願で締めたいと思います。
GeminiCLI、 ClaudeCodeのツールの違いはどうか
GeminiCLIは無料で使える範囲、ClaudeCodeは Pro版を使ってます。
webの検索能力はGeminiCLIのほうが新しい情報取ってくることに関しては強いと感じました。
ファイルの中身を読みとって、修正する能力やサンプルで出してくるプログラミング能力に関してはClaudeCodeのほうが強かったです。
ただこも、定量評価できないため、判断が難しいところです。
AIツール全般に言えますが、結局、いろいろ使い分けみて自分にフィットするものを見つけないといけないという課題があります。
従来のソフトウェア開発も自然言語のみで開発が可能なのか
前述でも書きましたが、あいまいな指示だけで、ViveCodingすると、
最終的には崩壊していって、破棄するということが何度も起きました。
今回考案したチケットAI駆動開発（仮）は、実際のプログラミング開発に対応できるように実験を進めています。
記事作成では主なタスクがチケット作成、記事作成、記事修正の3つで済みましたが、ソフトウェア開発プロジェクトの場合、目的が多岐にわたるため、タスクの一般化に苦戦しています。
- 一つのスプリント（機能要件定義から設計、実装、テスト、デプロイまで）を大きなタスクとして、抽象化・細分化していくのが良いのか
- 設計、実装、テスト、デプロイなど、非同期的に処理可能な一つ一つの工程をタスクとして細分化すべきなのか
など、プログラミングにおけるタスクの複雑さを改めて認識させられています。
私はAIが生成するコードをいまひとつ信用できていません。
- 同じプロンプトでも同じ結果にならない。(コードの一貫性が崩れ、品質が安定しない。)
- テストを無理やり通過させるために意味不明なコード改変を行う（これが最も困る点です）。
- 似たような機能を重複して実装する（技術負債が量産されます）。
- モデリング済みのオブジェクトを全く再利用してくれない（機能のごとのクラスにファイルを分割しているのに再利用してくれないなど）。
- SOLID原則を理解して，その内容を元にリファクタリングを提案する。（依存関係の逆転が起きないように役割を整理して参照を変更するなど）
- 全体の整合が取れるように構造を変更するようなリファクタリングが苦手．（重くなってきたクラス群を依存性注入でシンプルなど）
AI自身が出力したコードですら、AI自身がその内容を全く理解しいると思えないことが多いです（LLMのモデル構造を考えれば当然ではありますが）。
現状では、ほぼ全てのコードレビューやタスクの軌道修正が避けられないため、その点ではチャット型と比べて、コピペ作業が減った程度の生産性に向上と感じています。
ドキュメント作成が向いている説
エージェント型AIが最も生産性を向上させられるのは、資料作成かもしれません。
資料作成はソフトウェア分野のドキュメント作成に限らず，経営、営業、マーケティング調査など、多岐にわたる分野でビジネスパーソンの必須となるスキルです。
GeminiCLIと様々な生成AIサービスを連携させ、画像，動画などを使った美しいスライドコンテンツを量産するといった手法を誇らしげに紹介する記事を目にしたことがあります。
そういった場面で使われるドキュメントには、正確さよりも分かりやすさが求められるように感じます。
一次情報を求めるタイプの人以外であれば、その程度のドキュメント作成能力で十分であり、
その程度の能力しか持たない人はエージェント型AIによって代替されやすいと言えるでしょう。
(視覚的なわかりやさを重視した資料はフレーミング効果が生じやすく，よく正確性と混同され、誤った判断に繋がる可能性があるため，私はあまり好みません．)
ソフトウエア開発において何をエージェント型AIに任せられるか
私は、Docs as Code にのっとって、
ソースコードと別に詳細なドキュメントを作成したくないタイプです。
クリーンアーキテクチャを重視し、ソースコード自体のdocstringsを充実させ、ソースコード自体の品質に集中することが、
開発速度と品質のバランスがもっとも良いと考えています。
インフラを含むアーキテクチャを素早く手書きで描き、あとは直接コードで記述してモデリングした方が、曖昧さが入り込む余地がなく良いと考えています。
また、ドキュメント自動生成機能を持つフレームワークであれば、ソースコード上でちゃんと作りこんでおけば、わざわざドキュメントを更新する手間がなく、
開発に集中できます。
エージェント型AIともに開発する場合、エージェント型AIに指示するためにプロンプトを作成するタスクが発生し、かえって面倒さが増したように感じます。
これまでソフトウェア開発の場合詳細設計はコーディングしながら頭の中だけで考えながら定義したため、わざわざ言語化してきませんでしたが、
エージェント型AIに作業を指示する過程で強制的に言語化を意識させられました。
そういった意味では、エージェント型AIともに開発するには自然言語による言語化能力が必須だと感じます。
これには抽象化能力や論理的思考のような高い認知能力が必要で、それば自分も含め万人にもできるとは到底思えません。
よく、「エージェント型AIにはジュニアエンジニアに指導するような感覚で指示すれば良い」と言われます。
個人的には、その見解に対しては否定的です。
なぜなら、ジュニアエンジニアの指導は、個人的にはできれば避けたい作業だからです。
私はエンジニアを自称するのであれば、自分で学び、自律的に成長してほしいと思っています。
とはいえ、経験者が教えることで学習効率を上げられるのも事実です。
ジュニアエンジニアが早期に即戦力となってくれれば、自身の仕事が楽になり、会社の利益にも貢献するという投資的な理屈は理解できます。
人間のジュニアエンジニアの場合、育成するコストはかかりますが、教えた分だけ学習し、着実に成長していきます。
人間の場合はコンテキスト制限がほぼないと言っても過言ではありません（経験を積めば積むほど、少なからず成長してくれるはずです）。
だからこそ、世の中の優秀な上司たちは、長期的なメリットも考慮し、あえて部下たちに難しい課題を与えたり、失敗を許容したりする判断をするのだと思います。
しかし、AIは違います。物覚えが悪く、全く成長する意欲のない、無駄に学歴だけが高い新人エンジニアを指導している気分になります（プライドがないだけまだマシですが）。
プロンプトを工夫する行為は、AI君が成長しているわけでなく、扱う側が成長しているとも言えるのではないでしょうか。
このように、AIへの指示は、人間のジュニアエンジニアを指導する時のような状況とは異なります。
AIが失敗するたびに、「もういい、私が書く」という判断に至ってしまいがちです。
そうやって人が介入し、プロジェクトが大規模になると、プロジェクト全体を俯瞰するような広範なコンテキストをAIは徐々に読み解けなくなっていきます。
結果的に、最終的には小さなコンテキストの簡単なタスクしか任せられない「無能」と化してしまいます。
最後に
書こうと思ったきっかけはとある動画投稿サイトで非エンジニアむけClaudeCodeを使ったVibeCodingでアプリが出来るといううたい文句の動画をみたことです。
動画の演者自身も実務経験ないのかな？とうレベルでした。（ReactのチュートリアルでTODOアプリ作っただけでドヤってる感じです。）
そして動画の最後には使い方教えますとうクロージングが始まりました。
新しい技術って情弱だましてお金とる界隈のやつらにすぐ利用されいると思うと、見ていて悲しくなりました。
プログラミングにおいては、どこまでエージェント型AIに任せられるか、どのような指示を与えれば良いのか、まだ手探り状態です。
正直なところ、私はエージェント型AIを全く使いこなせていません。
残念ながら，情報商材業界の人々からすれば、私は時代遅れ（オワコン）となるタイプの人間なのかもしれません。
エージェント型AIの利用自体は、もちろん歓迎すべきことです。
チャット型AIに比べれば、ファイルを扱える、コードエディタ一本で開発できる、非同期で作業できるといった利点があり、もはやチャット型に戻ることは考えられません。
エージェント型AIは仕事でも積極的に活用していきたいのですが、工場で働く私には使用できないため、夢物語で終わりそうです。
ふとした思い付きのシステムを言語化しようと書き始めたら、思った以上に文量がおおくなってしまいました。
もし、最後まで読んでくれた方いらっしゃいましたら、ご拝読ありがとうございました。