AIエージェントはあなたのお金をどのように使うのか

論文が示した内容は私とっては「驚きの内容」ではなく、「実体験で感じてきた事の言語化」でした。それ故により真実味を持って受け止めました。 

第2部 — 研究が示した3つの事実

ここからは、論文と現場の観測から見える3つの現象を順番に見ていきます。

現象A:エージェントは「通常のチャットの 1000倍」消費する

図1. トークン消費量の比較

普通のチャット(数往復のやり取り)を基準にすると、エージェント — つまり「AI が自分で考えながら手を動かす」場合 — は、消費量がケタ違いです。だいたい 1000倍規模になります。

しかも、研究で分かったポイントはここ。

AI が出した答え(出力)よりも、AI に渡している情報(入力)の方が、料金の大半を占めている

つまり、課金の主役は「AI が頑張って考えて吐き出した結果」ではなく、「AI に毎回読み込ませている文脈」の方なんです。

現象B:使えば使うほど料金は膨らむ。しかも賢くはならない

図2. 情報量と賢さの関係

直感的には「情報を多く渡す = AI がより賢く答える」と思いますよね。実際はそうなってなかった、というのがこの論文の発見です。

• 料金は青天井(渡せば渡すほど、消費トークンは増える)
• でも、精度は途中で頭打ちになる
• それどころか、その後は逆に 劣化 することがある

「お金を積めば賢くなる」が成立しない、という話です。

現象C:同じ仕事を頼んでも、料金は毎回バラバラ

図3. 同じタスクを6回実行したときの消費量

同じタスクを何回かエージェントに投げて、消費トークンを記録するとどうなるか。最大で 30倍 くらいの差が出ます。

しかも、

• どれだけ消費するかは、やってみるまで分からない
• AI 自身に「どれくらい使う?」と聞いても、正確には答えられない
• しかも見積もりは、たいてい実際より少なく出る

予算管理する側からすると、これは結構しんどい性質です。

3つの事実は、すべて同じ原因から来ている

ここまでの3つ — 「1000倍消費」「料金と精度のミスマッチ」「実行ごとのばらつき」— は、それぞれバラバラの問題に見えます。でも実は、ひとつの構造的な原因 から来ている、というのが次の章の話です。

生成AIの静かなるターニングポイント

 こんにちは、横井です。

昨年(2025年)の年末からこの4ヶ月くらいは、生成AI及びエージェントツールに関しての状況が激変でした。LLMのモデルの進化以上に、エージェントツールの進化がもの凄く、毎日アップデート版がリリースされてきました。

特に、Claude Coworkがリリースされた時、Anthropic社の人は「Claude CoworkはClaude Codeを使って10日間で完成させた。100%AIコーディング」とコメントして我々を驚かせました。もはや、製品やサービスを提供する側はAIコーディングによって開発をしないと、スピードが追いつかない状況に突入したのです。

そんな中で、私の状況としては既存資産(大規模なソースコード)の解析だったり、AIコーディングを実戦レベルで重ねてきました。色々な経験値が貯まってきましたので、新たに発見した事、今の状況に思う事などを、つらつらと纏めてみました。

第1部 — AI を「定額で使い放題」の時代は、静かに終わりつつある

ここ数ヶ月、料金まわりで大きい動きが続いています。

• 2026年4月 — Anthropic が Claude Code の Pro プランからの除外を一時テスト(撤回後も方針自体は継続)
• 2026年4月 — GitHub が Copilot の全プランを 6月1日から従量課金制に変更すると発表
• 他社含めて、サブスク利用枠の段階的な引き締めが続いている

ざっくり言うと、これまでの「定額で重く使える」状態から「使った分だけ払う」体系へ、業界全体が動いています。

これは値上げの話じゃなくて、構造的な転換のサインだと思っています。

きっかけになった研究

ちょうど良いタイミングで、こんな研究論文が出ました。

How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks Longju Bai et al. / ミシガン大学・スタンフォード大学他 / arXiv:2604.22750

主要な発見は3つ。

1. エージェントが消費するトークンは、通常のチャットの 1000倍規模
2. 消費量の中身は、AI の出力よりも「入力(渡された情報)」の方が大半
3. 高い料金を払ったからといって、AI が賢くなるわけではない(精度は途中で頭打ち)

…なかなか衝撃的じゃないでしょうか。

このブログで考えたいこと

最初の問いはシンプルに

「なぜ AI エージェントは、こんなに高くつくのか?」

ただ、調べていくうちに、本当に向き合うべき問いはこっちなんじゃないかと思うようになりました。

記憶を持たない AI に、複雑な仕事をさせるには何が必要か?

このブログは、後者の問いの答えを探す話です。

イノベーティブ・ソリューションズは本社を田町に移転しました

 ご無沙汰しています、横井です。

2026年も気が付けば4ヶ月が過ぎました。このブログも5月になって今年初めての投稿です。

さて、株式会社イノベーティブ・ソリューションズは2026年3月末で本社(横浜)及びワーキングオフィス(大崎)から田町に引っ越しをしました。これは2024年に株式会社パワーソリューションズにグループインしましたが、グループシナジーを高めるために親会社とグループ会社併せて5社が同一拠点にオフィスを集約する事になりました。

【新住所】
〒108-0023
東京都港区芝浦三丁目1番1号msb Tamachi 田町ステーションタワーN　31F

OpenAI o3は、もはやエージェント

こんにちは、横井です。

前回の投稿から少し時間が経ちましたが生成AI界隈は相変わらずの激しい進化を見せています。先日公開されたOpenAI のo3モデルですが、公開直後からこれは凄いと投稿が相次いでいました。

私も試してみたところ、これはびっくりしたというレベルを通り越してびっくりしたので、共有しておきます。ChatGPTでモデル「o3」を選択し、自分のスマホで撮影した画像を添付し「ここはどこ?」と問い合わせするだけです。

xで色々と投稿されていたので、「ビルとか背景が判明しやすいものが映り込んでいると簡単だろう。なるべく人工的なものが少ない風景写真が難しいのでは?」といじわるで電車と桜が写っている写真を使ってみたところ。。。

まずは画像の解析を始めましたが、この解析のプロセスがそのまま画面上で展開されているのですが、写真全体の中から場所を特定する材料が無いか探し始めます。その場はPythonコードを生成・実行し、写真の中から特定の場所をズームするように切り取ります。そうした材料探しを繰り返しある程度仮説が立てられるような情報を得られたら、今度はネットを検索し、仮説が合っているかどうかの検証をし始めました。

結果は見事正解でした。この結果はびっくりしたなんてレベルではないですね。

動作的にはDeep Researchの進化系な感じですが(特に後半の仮説検証の検索はDeep Researchそのまま)、前半の画像を解析するところでは「これは何か推測の材料になるのでは?」とズームを繰り返す所が、まるで人が謎を解くかのように写真を隅から隅まで眺めているようで、本当にコンピュータによる処理なのか?!と疑ってしまうほどでした。

この一連の動きはもはやエージェントと言っていいものだと思います。与えられた命題に対して、それを達成するための手段として複数のツールを持ち、その時の状況でツールを使い分けて、かつ、命題を達成するためのステップを自律的に考えて、最終的にゴールにたどり着く。というエージェントの定義そのものの動きです。

もう一つ、会社の近くの目黒川沿いの桜(イルミネーション)で試してみましたが、これも見事正解でした。

ここ数ヶ月での生成AIの進化の凄まじさに驚くと共に、こういったリサーチ系の機能は良い使い方もできれば、犯罪の手助けにもなる(個人情報の特定が可能)という意味では、より一層使う人間側のモラルが問われるもだと思いました。

では。

人に易しい事、AIに易しい事

こんにちは横井です。 

基本的にAIコーディングはLLMがフレームワークまたはライブラリ、そしてアーキテクチャやデザインパターンなど学習済みの言語が対象であれば、コーディングはすごく容易いことです。一方、学習していないことに対しては、LLMは知らない部分は自分で補完しようとするので、これがいわゆるハルシネーションという架空のアウトプットを出してしまいます。

人によっては嘘をアウトプットしてると言われることにもなっています。

生成AIが世間で騒がれるようになってから私もGeneXusエバンジェリストとして生成AIがGeneXus言語でコーディングできるのか?ということにはずっと取り組んできました。GPT-4がリリースされてから2年近く経過している今現在ではGeneXusに関する学習がされていると感じられるアウトプットは結構増えてきています。ただそれは十分なカバー量ではなく、他の学習済みの言語のようなレベルにはほど遠いというのが現状です。

文法を学習してないと言う事に関しては、カスタムインストラクションの中に言語の文法や他言語とのマッピングというような形で情報を追加してあげれば、ある程度アウトプットを再現する事はできます。

ただどうしても難しい事があります。GeneXusではSQLは一切書きません。SQLを書かないと言う事はテーブルの指定もしない。そしてテーブル間のJOINの指定をしません。

指定するのはデータを抽出したい項目名とそれらに対する条件(抽出条件やソートオーダー)です。この文法 - for eachコマンドになりますが、命令に関しては他の言語に例を見ないGeneXus特有のものです。

その発想の話は過去の記事に記載があります。

• GeneXus Day 2011 Winterが開催されました
• 【コラム】4) ユーザービューとは? (GeneXusとDOA)

要約すると、DBアクセスに関しては裏側の技術知らなくてもシステムの表面上、見た目上で必要な項目さえ与えてあげれば後はGeneXusが推論し、SQLを生成する。というものです。

従って、GeneXusが解析するGeneXus言語上での指定は先に言ったとおり、「データとして必要となる項目」だけです。

しかし、AIコーディングでは「データを抽出する」と言うキーワードが入った瞬間に、LLMはSQLを想定し、あるいはSQLを使ったライブラリーのAPIを想定したコードを書いてしまいまい、GeneXus言語でのfor eachコマンドにはならないのです。

DBアクセスという難しい操作を人に易しくする為に考え出されたGeneXus言語 : for eachコマンドですが、LLMの学習状況を踏まえるとAIにとっては再現するのは難しい事で、なんとも皮肉な状況になっています。

では。

卵が先か？鶏が先か？AIコーディングはプロマネ育成ツール

こんにちは、横井です。 

先日、AIコーディングについてあるお客さんと雑談していた時の事です。私が「AIコーディングが普及すると、要件定義力と開発方法論に基づいたプロジェクトマネジメント力があれば、ソフトウェア開発はできてしまう」といった話をすると、「てことは、プロマネがいれば開発ができるけど、プロマネはどうやって育成したらいい？普通はコーディングから始まって一通り開発プロセスを経験の上に成り立つものだよね？AIコーディングを推進して実践する場が無くなったらプロマネ自体が育たないよね?」と、言われました。

確かに。私がAIコーディングを経験して「こりゃ凄い！人に依頼してるのと変わらない！」と感じることができるのは、年齢も50代半ばに差し掛かり、30年以上ソフト開発の現場に関わってきたからこそ。というのは事実です。

その時は「仰るとおりです。ただ、AIコーディングが普及することで例えばサービス会社は状況が180度変わります。人員不足の世の中で猛烈なスピードでサービスを開発する事が可能になります。では、SIerやIT子会社といった開発を生業とする会社はどうなりますか？AIコーディングとの向き合い方はどうしますか？そこは問われてくると思います」と答えました。

そうは言ったものの、確かにその通り。どうしたものか。。と考え込みました。

あれこれ考えた末たどり着いたのは「コーディングを出発点として一通り開発プロセスを学ばなくてもマネジメントを学ぶことは可能」でした。

日本では徒弟制度とか、経験第一主義な所はありますが、これはよくある議論で実戦を積まないと出来ない派と理論を学べば出来る派の話になります。が、私の結論はそのハイブリット的なものです。

私の発想は「要件定義力やマネジメント力があればAIコーディングが成立する」というものです。これは逆に言うと「要件が明示的に伝えられず、プロセスに基づいたマネジメントもできないと、まともなコーディングをしてくれない」という事になります。そしてこれは私自身もAIコーディングとして経験しましたが、「どうやったらまともなコーディング、まともなアプリが実装できるのか?」という事を考えながらトライ&エラーでAIコーディングを続ける事で(今時点での)ベストプラクティクスに辿り付きました。つまり、AIコーディングを実践すること自体が開発経験を積むのと同じ事だと思います。

要はAIコーディング自体をトレーニングとして実践することで、マネジメント経験やプロセスの必要性を身をもって体験できます。しかも通常の開発では半年、1年と期間をかけないと一通りのプロセスの体験は出来ませんが、AIコーディングならもっと短いスパンでサイクルを経験することができます。

「AIコーディングでは実際の開発をしている訳ではないから、経験にならないのでは?」という意見もあるかもしれません。それであれば、新人教育の中で技術習得の前にAIコーディングによるマネジメント体験をさせれば、その後の技術教育やOJTでもマネジメントの必要性、重要性をわかった上で取り組むことが出来るのではないでしょうか？また、今時点では全ての開発がAIコーディングに取って代わられるわけではありません。実戦経験のチャンスは十分ありますので、教育の一貫として取り組んでみるのもいいと思います。

生成AIを色々体感した上で、周りの人と会話すると若干かみ合わない事が出てくるのですが、ある意味「突拍子もない事、突拍子もない発想」というのが生成AIが存在する今現在、そしてこれからの未来では必要なのではないでしょうか。

では。

AIテストは信用できる? AIテストの外堀の埋め方

こんにちは、横井です。

前回はAIコーディングに対する品質担保についてお話ししました。結論としては人がコーディングしようが、AIがコーディングしようが、設計通りに実装できているか? を確認するにはテストが必要。というごくごく当たり前の話でした。(笑)

もう一つは生成AIでもテストコードは生成可能という話です。しかし、そのテストコードがどれだけ信頼できるかは、作成方法や段取りに大きく依存する問題でもあります。

一般的な開発プロセスでは、まず設計を行い、次にアプリケーションコードを作成し、最後にテストコードを作成するという流れになります。しかし、その場合、テスト実行時にエラーが発生した際、問題がアプリケーションコードにあるのか、テストコードにあるのか判断が難しくなるという課題があります。これはAIコーディングに限らず、スクラッチでの開発においても同様の悩みとなります。つまり、アプリケーションコードの品質を担保するためにテストコードが必要となり、そのテストコードの品質を担保するためにさらにテストコードが求められる、いわゆる「テストコードの無限ループ」問題に突き当たります。

このような問題に対する解決策として、TDD（テスト駆動開発）の手法が提唱されています。TDDとは、アプリケーションコードを作成する前に、まずテストコード、すなわちテストケースを作成し、その状態で初めてアプリケーションコードを実装するという流れです。常にテストコードを実行し、テスト結果がグリーン（合格）の状態を維持することを重視する考え方です。

ただし、TDDのポイントは単にテストコードを先に作成することではなく、まずはテストケースを漏れなく洗い出すことにあります。そしてそのためには、十分な設計が不可欠です。設計が整っていなければ、網羅的なテストケースの洗い出しは難しくなります。つまり、TDDとは、テストコードを作成するためにテストケースを検討し、その検討のために設計をしっかり行うという、一連の決められたプロセスに基づいてワークフローを回すことが肝心なのです。

以上の話はスクラッチ開発での一般的な話ですが、実際にはこの方法論はAIコーディングにおいても十分に適用可能です。常にテスト結果を確認しながら開発を進めることで、生成AIの高速なコーディング能力と、求める品質の両立が実現できると考えます。

では。

---

すみません、追記です。

TDDを実践することでコードの品質を上げることができると書きましたが、この場合当然の事ながらテスト実行の回数が増えます。CLIベースのテストツールだと、テスト実行中のモニタリング情報を秒単位で出力します(画面でリフレッシュさせているような感じ)。結果として、例えばエラーが1つしか出なくても、テストが完了するまでのモニタ表示用の出力が延々と続き、結果としてLLMへの送信量が莫大になります。しかも、膨大なログを解析するの時間もかかり、結果一つしかエラーが無いとか、エラーがゼロとかだと、API呼び出しの待ち時間とコスト消費が馬鹿になりません。(あっという間にチャージしたクレジットが溶けていきます)

これはAIコーディングを品質良く実施する事の可否と、技術的コスト的問題は別物であるという事です。なので、私のブログを見たからといってすぐさまTDDに取り組むのであればそれなりのお金の消費を覚悟する必要があります。

では。