2026.04.12

私が外した未来予知2026

私が外した未来予知2026

執筆: 小手川周平 (CEO)

足元のAI技術から数年後を予測するのは、昔から比較的得意で好きでもある。今回はあえて、自分が外した予測と、そこから見えてきたこれから賭けたい未来を書いてみる。

外れた未来予知①LLMが進化してもコーディングの質は大きく上がらない

自分が最初に本格的にAIをコーディングに用いたのは2025年初頭のCursor、Devinが台頭しClineが一瞬話題になった頃だった。

その頃のAIは、指示する側でもある程度実現イメージが湧いているような比較的単純なタスクや改修対象が1ファイルで収まるようなタスクを丁寧にプロンプトを書いて指示すれば上手くやってくれてはいた。

ただコーディングの質はプロンプトを出す側のスキル・知識・文章力に大きく依存しており、運転席に座らせるというよりは助手席で補助的にヘルプしてくれる存在として意識していた。

個人的には、コードを書くという行為においてこれ以上質を高めていくためには渡すべきコンテクストを圧倒的に増やす必要があるが、文書化されていない情報も含め人間がAIに渡せるコンテクストの量には物理的な限界があるので、いくらモデルや推論力が進化してもAIの開発力が爆発的に上がることはないだろうと考えていた。

なぜ外したか

①CLIベースのコーディングエージェントの誕生

単に「CLIで動くようになった」という話ではなく、開発の単位が「ファイル単位の編集」から「タスク単位の実行」に変わったのが本質だった。従来は人間がエディタで1行ずつ修正していたのに対して、エージェントは「機能追加」「バグ修正」「リファクタリング」といったまとまりで仕事を引き受ける。

さらに、CLIという形に落ちたことでCI/CDやテスト、ビルドと自然に接続され、コードを書くだけでなく「実行→失敗→修正→再実行」のループを自律的に回せるようになった。このループを人間が介在せずに高速で回せる点を軽視していた。

結果として、単発のコード生成の精度以上に「試行回数」と「収束速度」で人間を上回り、総合的なコーディングの質が上がった。

②予想を上回る推論力とコンテクストウィンドウの拡大

1年前の自分は、AIの開発力は「人間がどれだけ適切にコンテクストを渡せるか」に強く制約されると考えていた。長いコードベースや暗黙知の多いプロジェクトでは、人間が前提を整理して伝えること自体に限界がある。モデルの性能が上がっても、その制約を越えて開発の質が大きく伸びることはないという前提だった。

実際には、コンテクストウィンドウの拡大と推論力の向上によって、AIは与えられた情報だけで動く存在ではなくなり、必要なコンテクストを自ら取りに行く存在に変わった。エージェントはリポジトリ全体を走査し、コードだけでなくローカル・本番のログやドキュメントも横断的に参照しながら、変更に必要な前提を自分で収集する。コンテクストは「人間が渡すもの」から「エージェントが探索して獲得するもの」へと変わった。

重要なのは、単に多くの情報を扱えるようになったことではなく、長いコンテクストを維持したまま整合性を保ち、依存関係や設計意図を踏まえた変更ができるようになった点にある。従来は局所的に正しいコードを書けても、複数ファイルにまたがる変更では破綻しやすかった。この制約が推論力の向上やCLIベースの開発ループによって大きく緩和された。

また、価値の中心も変わっていた。コード生成そのものではなく、開発プロセス全体を扱えるようになった点が本質だった。テスト生成、リファクタリング、依存関係の解決、実行と検証といった工程をエージェントが自律的に回すことで、成果物の質は個々のコードではなくプロセス全体で引き上げられる構造になった。人間の説明能力がボトルネックになるという前提自体が成立しなくなっていた。

とはいえ、現在の技術においてもAIに完全に依存したシステム構築には品質やリスクの面で課題が残っている。それらを補うための「ハーネスエンジニアリング」のようなベストプラクティスも登場しているが、こうした知見もAIエージェントやモデルの進化に伴い刻々とシフトしていくものだろう。その動向は引き続き注意深く見守っていきたい。

外れた未来予知②MCPという技術がソフトウェアのあり方を大きく変える

MCP(Model Context Protocol)のような仕組みが普及することで、あらゆるソフトウェアがAIにとって扱いやすい形で接続され、最終的にはUIの主役が人間向けの画面からAI向けのインターフェースへと移行していくと考えていた。

極端に言えば、ユーザーはChatGPTのようなインターフェースだけを触り、裏側では複数のサービスがMCP経由で連携される。個別のアプリを意識する必要がなくなり、ソフトウェアは「呼び出される関数群とデータベース」に近い存在になるという予測だった。

ただし現時点では、MCPの将来性には引き続き期待しているものの、そのような変化はまだ限定的にしか起きていない。

なぜ外したか

①確実性、再現性、精度が求められる業務との親和性

MCPのような柔軟な接続は魅力的だが、実務の現場では「毎回同じ入力に対して同じ結果が返ること」が強く求められる領域が多い。特に決済、在庫、会計などでは、曖昧さや確率的な挙動は許容されない。

そのため、多少柔軟性が低くても厳密に仕様が定義されたAPIの方が信頼されやすく、MCPのような抽象化レイヤーは「便利だがコア業務には使いにくい」というポジションに留まりやすかった。

結果として、実験的な連携には使われても、コア業務を置き換えるレベルには広がっていない。

MCPの精度問題に対して、freeeの公式freee-mcpのアプローチは興味深い。ここではMCPサーバーが単にAPIを呼ぶだけでなく、別途Agent Skillsを用意し、APIリファレンスや操作レシピをエージェントが段階的に参照できる構造にすることで正確な利用をガイドしている。freee-mcpの設計はコンテキスト効率化を意図しており、業務固有の手順や制約を構造化して必要なタイミングで渡すことで、エンドポイントが多いAPIでも精度を維持しやすくしている。

この方向性は海外でも見られ、MicrosoftはAzure向けの公式Agent Skills群を、Vercelも公式のagent-skills集を公開している。Anthropic自身もskillsをspecialized tasksの性能向上手段として位置づけており、実務でのMCPは「モデルの能力」以上に「何をどう教えるか」が重要になっている。

②APIやその認証基盤が整っていないサービスが多くエコシステムが育ちにくい(特に国内サービス)

MCPは前提として「外部から安全に呼び出せるAPI」が存在することを要求するが、日本のWebサービスはそもそもAPIが公開されていなかったり、あっても粒度が粗かったりするケースが多い。

加えて、OAuthなどの標準的な認証基盤が整っていない、もしくは導入されていても制約が厳しいサービスも多く、AIから安全に横断的に操作するための土台が不足していた。

この結果、MCPに対応したとしても接続できるサービスが限られ、「繋がると便利」というネットワーク効果が立ち上がらなかった。

そもそも通常の業務は単一のアプリで完結することが少なく、複数のサービスを横断的に操作してはじめて一つの業務フローが成立する。個別のサービスがMCPに対応しても、業務に関わるサービス群がエコシステムとして揃わない限り、もたらされる便益は限定的なものに留まる。

外れた未来予知③ChatGPT Apps SDKがスーパーアプリ化してあらゆるアプリを飲み込む

ChatGPT Apps SDKは2025年10月に発表されプレビュー提供が開始された。

簡単に言うと、ChatGPTの中にサードパーティアプリを組み込み、ホテルやレストランの予約やプレイリストをユーザーにサジェストしてくれるという思想で、個人的には様々なアプリケーションが1つのアプリから呼び出せることで人が触れたり覚えたりしないといけないアプリが減りかなり楽になるのではと考えていたが、現時点では、少なくとも日本市場において明確な普及の兆しはまだ見えていない。

なぜ外したか

①キラーアプリの不在

Apps SDK自体は汎用的な基盤だが、「これのためにChatGPTを開く」という強い動機を生むアプリが現れていない。多くのユースケースが既存アプリの代替に留まり、「置き換えるほどではない便利さ」にとどまっている。

また、LLMの特性上、出力が毎回微妙に揺らぐため、検索や予約のように結果の正確性・網羅性が重要な領域では専用アプリに劣後しやすい。結果として、日常的に使われる導線に入り込めていない。

②ユーザーの行動変容コスト

既存アプリは通知、履歴、パーソナライズなどを通じてユーザーを囲い込んでおり、単に機能が同等というだけでは乗り換えは起きない。特にスマホのホーム画面にあるアプリを開く行動は強く習慣化されている。

ChatGPTは「何でもできる」がゆえに、特定用途に最適化された体験では劣る場面も多く、結果として「たまに使う便利ツール」の位置に留まっている。

長期的には、toC・toBを問わず、用途ごとにアプリが分かれた世界から、統合的なアプリ上で複数の目的を達成できる世界へ移行していくと今も考えている。ただ、その変化には想像していた以上に時間がかかりそうだ。

ECUがこれから賭ける未来

3つの予測を振り返ると、共通する見誤りのパターンが見えてくる。技術の進化速度は予想より速い一方で、それが社会やユーザーの行動を変えるスピードは予想より遅い。この非対称性を踏まえた上で、ECUがこれから注力していく領域を2つ挙げたい。

①セキュリティ・ガバナンス領域の重要度が増していく

Anthropicは先日、Claude Mythosのsystem cardを公開し、特にコンピュータセキュリティ領域で高い能力を示したと説明している。「能力が高すぎるため一般公開を見送った」という説明をどこまで額面通りに受け取るかは意見が分かれるところだが、モデルの進化に伴いセキュリティリスクが高まっていく方向性自体は間違いない。

そしてリスクはモデル側だけの話ではない。AIを導入する側にも、適切な人が適切な権限で安全にAIを利用できるよう、ガバナンスやポリシーの整備がマストになる。素早くAIアプリケーションを構築すること自体は誰にでもできる時代になったが、安全にAIを運用し続けることの難易度と重要性はこれから上がり続ける。ECUは「セキュリティ・安定運用特化のAIカンパニー」として、この領域に正面から取り組んでいく。

②AIの恩恵を阻むボトルネックの解消

LLMが登場する前にベストプラクティスとされていたものが、今の時代では逆にAIの恩恵を阻む要因になっているケースが増えている。

たとえばノーコードツールは、人間が直感的に操作できる反面、ソースコードとして管理されていないためにAIが参照・編集することが難しく、結果として人間の手作業によるメンテナンスが必須のままになっている。同様に、GUIベースの管理画面やスプレッドシートで運用されている業務プロセスも、AIエージェントからは操作しにくい構造になっている。

あらゆるツールやワークフローを「人間が使いやすいもの」から「AIが扱いやすいもの」へとシフトさせていく必要がある。APIやCLIの整備、データの構造化、認証基盤の標準化。この記事で触れたMCPやAIエージェントのエコシステムが育ちきらない原因とも直結する課題であり、ECUはこの転換を支援する立場に賭けていく。

ECUでは、自社サービスをAIエージェントやMCPサーバーと接続するためのAPI・CLI開発を支援しています。また、ノーコードツールからコードベースへの移行についても、STUDIOやWordPressなどからのCMSのコード化(内製化)サービスを提供しています。ご関心のある方は、ぜひご相談ください。

SNSでシェア