KNOWLEDGE - COLUMN ナレッジ - コラム

「2026年、AIはここまで来た」エンジニア視点の最前線

AIトレンド

関連するソリューション

業務改革

AI

AIスマートソリューション部
テクニカルスペシャリスト     
松尾 大輔 matsuoka2_274x380

 
こんにちは。AIスマートソリューション部テクニカルスペシャリストの松尾です。4月になり2026年度がスタートしました。本年度もAI界隈では様々なテクノロジーの登場が予想されます。そこで今回のコラムでは、2026年度のAIテクノロジートレンドについて、エンジニア目線で現状の整理と今後の考察を行ってみたいと思います。

マルチエージェント

昨年度に引き続き、マルチエージェントの実装や導入が加速していくと考えられます。昨年度は、AIと外部ツールを繋ぐ共通仕様としてMCP(Model Context Protocol)が、エージェント間の連携を標準化する共通仕様としてA2A (Agent2Agent Protocol)が、それぞれ策定されました。MCPにおいては、Visual Studio Code(VSCode)をはじめ、既に様々なツールに組み込まれています。A2Aにおいては、複数のマルチエージェントを連携させるユースケースが現時点では稀であることから、本格的な普及はこれからといった段階です。
 
エンタープライズレベルの実装においても、今では多様な選択肢があるので、開発チームのスキルセットを鑑みて実装方法を選択する必要がありそうです。

各クラウドベンダーが提供しているマネージドサービスを利用

AWS、Microsoft Azure、Google Cloudの3大クラウドにおいては、提供されている生成AIのマネージドサービスの中でマルチエージェントを実装できます。
 
Amazon Bedrock AgentCore

Foundry Agent Service
 
Vertex AI Agent Engine

これらのサービスで既に生成AIのアプリを実装したことがある方は、その延長としてエージェント実装に取り組むことができます。ただし、マネージドサービスであるが故に、クラウド利用者が設定できない(クラウドベンダーの責任範囲)箇所もあり、セキュリティを始めとした非機能要件を満たせなかったり、複雑なエージェントでは挙動に制限が生じたりする可能性があります。
 
当社では、AzureのFoundry Agent Serviceでマルチエージェントを実装したことがあるのですが、エージェントが使用する各種ツール類をPrivate Endpoint接続に全て統一することができませんでした。また、「親エージェント - 子エージェント - ツール」の階層が5階層までという制限があったので、複雑なエージェントは処理を行うことができないこともありました。

Difyなどのローコードツールを利用

エージェント部分は、Difyやn8nなどのローコードツールで作成して、それを実行させるためのインフラ部分は、各クラウドのIaaS/PaaSを利用して実装する方法です。AIエンジニアはエージェントの振る舞いやエージェントが呼び出すツール等、いわゆる「コンテキストエンジニアリング」に集中することができます。ただし、インフラ部分は従来のシステム開発となりますので、インフラ(クラウド)に精通したエンジニアがチームに必要となります(ユーザー認証はどうする?といった議論は毎回話題になります)。例えば、AWS上で実装するならば、下記構成のように認証にAmazon Cognitoを使用するといったことが考えられます。
 
AIトレンド
図1-1: ローコードツールを用いた実装例(AWS)

フルスクラッチで実装

ローコードツールは簡単に実装できる反面、要件によっては、細かいところが実現できない可能性もあります。このようなシチュエーションにおいては、フルスクラッチで実装することになります。その際は、GoogleのADK(Agent Development Kit)やMicrosoftのAgent Frameworkを使用して実装するケースが想定されます。(もちろん、OpenAI APIやLangGraph等でも実装可能です)。これらのSDKを利用することによって、Pythonのコーディングスキルがある人ならば、さほど苦労せずに実装可能です。特にADKはチャットのUIも標準搭載されているので、PoCレベルの実装ならば比較的容易に実装できます。
 
Agent Development Kit (Google)
 
Agent Framework (Microsoft)

いずれの実装方法においても、昨年度1年間で大きく機能が追加されてきました。本年度も新しい機能がどんどん追加されて、エージェント開発のハードルがさらに下がるのではないかと思っています。

AIトレンド

AI駆動開発(仕様駆動開発)

開発することそのものにAIを活用する「AI駆動開発」も導入が進んでいくものと思われます。既に大手SIerはソフトウェア開発全般に生成AIを用いることを宣言しています。以前はコーディングの補助程度だったものが、要件定義~設計~実装~テストといった全フェーズに生成AIが適用されていくことになります。AIを用いた開発と言えば、Vibe Codingが昨年度はバズワードでした(私もVibe Codingに関するコラムを執筆しました)が、Vibe Codingでシステム開発を行うには、以下のような事象が起きるため、本格的なシステム開発には不向きでした。

  • AIに繰り返し修正させたコードなので、開発者自身もよくわかっていない(開発者のスキルによりますが…)
  • 設計書などのドキュメント類がない(後付けで作成)

そのため、開発にAIを用いる場合は、コード生成の前に、仕様書類を準備して、そのドキュメントを「信頼できる情報源」とする 仕様駆動開発(SDD: Spec-Driven Development を行っていくことになります。これは、要件定義書や各種設計書を1ドキュメントずつAIに作成させて、それを人間がレビューするというAIと人間で合意を取って進めていく手法にもなります。これらドキュメントに「何を実装するのか、どうやって実装するのか」を明確に記載します。AIは、これらドキュメントを参照した上でコード生成等の実装を行います。これによって、ドキュメント類が開発チーム間、および開発チームとAI間の契約として機能し、「何を作るべきか」の認識相違を防ぐことができます。
 
なお、仕様駆動開発を行うにあたって、以下の点を意識する必要があります。

標準ルールを明文化する

AGENTS.mdやCLAUDE.md(Claude Codeを使用する場合)というファイルをプロジェクトのルートディレクトリ(ルートリポジトリ)に作成するのですが、これは、SDDを行う生成AI(エージェント)のメモリとなります。つまり、コンテキストの永続化のために使用します。ここには開発プロセス、各仕様書に記載する内容、設計方針、命名規則、コード規約、テスト規約など、開発を進めるうえで遵守する標準ルールを記載します。社内の開発標準として明文化されていればいいですが、そうではなくて、暗黙知として代々受け継がれているような場合は、明文化する必要があります。

AIトレンド

ドキュメントは生成AIと相性がいいフォーマット(Markdown)にする

2.1.のAGENTS.mdもそうですが、生成AIが参照および生成するドキュメントは、生成AIと相性がいい(つまり精度に直結する)Markdown形式にする必要があります。UMLのような図はMermaid形式として、Markdownの本文中に記載します。WordやExcelで作成した既存ドキュメントを流用する場合は、Markdown形式にコンバートしておく必要があります。生成されるドキュメントもMarkdown形式となりますので、ドキュメントのフォーマットはステークホルダー間で同意しておく必要があります。Markdownはそのままでは読みにくいので、VS Code等でプレビューしたものをPDFやHTMLにエクスポートして閲覧用とするのがいいと思います。なお、SDDに限らず、Markdownでドキュメントを作成することには以下のメリットがあります。

  • ソースコードと合わせて、Gitで管理することができる(=更新履歴を手動で管理する必要がない)。
  • 誰が書いても見栄えが同じになる。

以上を踏まえて、SDDの一連の流れを図にしたものが以下になります(この図もオリジナルはMermaid形式になります)。

AIトレンド
図2-1: 仕様駆動開発の流れ

ローカルLLMを活用したドメイン特化AI

2026年早々にOpenAIやAnthropicがヘルスケアに特化したサービスを発表しました。ヘルスケアに限らず、特定ドメインに特化した生成AIサービスは今後も増えていくものと思われます。
 
一方で、医療分野や金融分野等の規制業種では、データの機密性やコンプライアンス上の制約から、インターネットに接続することができない環境もあり、そういった場合においても生成AIを用いた業務改善を行いたいという要望があります。このような環境では、クラウドサービスとして提供されているOpenAIやGemini等をそのまま利用することができません。そこで、オフラインで動作可能なローカルLLMを用いることになります。ローカルLLMは日本語の精度が低い傾向があるため、ChatGPTやGemini等と比べて実務レベルでの利用が困難という印象がありましたが、TranslateGemma等、翻訳に特化したローカルLLMを間に介するという方法が一案として考えられます。


図3-1: TranslateGemmaを間に介したローカルLLMの例

または、日本の大学や研究機関等が公開している日本語モデルを使用することも考えられます。例えば、東京科学大学と産業技術総合研究所がファインチューニングした「GPT-OSS Swallow」は、日本語タスクが最高性能(2026年3月時点、総パラメータ数が120B以下のオープンなLLMにおいて)であり、商用利用も可能なライセンスであるため、有力な選択肢になるのではないでしょうか。
 
GPT-OSS Swallow
 
NVIDIA DGX Sparkが登場したことによって、ローカルLLMを動かすための計算資源のコストが下がったことも、普及の大きな後押しとなります。当社でも1台導入しましたが、gpt-oss-120bを動かすことができています。RTXシリーズのようなコンシューマー向けGPUでは動かすことができない大きなモデルを動かすことができるので、少人数の利用でスモールスタートする場合は、十分に実用可能だと思います。

フィジカルAI

2026年の新しいキーワードとして、「フィジカルAI」があります。フィジカルAIとは、チャットやテキスト生成にとどまらず、ロボットや自動運転車のように現実世界で動くAIのことです。生成AIの技術がロボットの「脳」として使われるようになったと言った方が分かりやすいかもしれません。1月にラスベガスで開催されたCESにおいて、NVIDIAのジェンスン・ファン氏が基調講演でフィジカルAIについて語ったことは記憶に新しいと思います。ファン氏は基調講演で「フィジカルAIにChatGPTモーメントが来た」と宣言し、AIが現実の物理世界で動く時代の到来を示しました。それを象徴するように、CES 2026の会場ではBoston DynamicsやNEURA Robotics、LG Electronicsなど多数のヒューマノイドロボットが展示され、まるでロボット博覧会の様相を呈していました。以前のCESはテレビ等の最新家電のイベントでしたが、すっかり様変わりしました。
 
NVIDIAはエンジニアがフィジカルAIを開発するためのプラットフォームとして「Isaac」を提供しています。Isaacはシミュレーター(Isaac Sim)、強化学習フレームワーク(Isaac Lab)、ROS 2対応のロボット知覚パッケージ群(Isaac ROS)、そしてヒューマノイド向けの汎用基盤モデル(Isaac GR00T)から構成されており、シミュレーションから実機展開までをワンストップでカバーします。Isaac Labや GR00Tのモデル等はオープンソース・オープンウェイトで公開されており、誰でも試すことができます。
 
このようなオープン化の動きは、研究機関でも起きています。東京大学・情報システム工学研究室(JSK)が開発した4脚ロボット「MEVIUS」は、CADデータから強化学習のコードまで、ハードウェア・ソフトウェアの全情報をGitHubで公開しています。部品の多くはEコマースで調達可能な設計になっており、個人でもロボットを作れる時代になりました。
 
MEVIUS(東京大学 情報システム工学研究室)
 
フィジカルAIはNVIDIAのような大企業だけでなく、こうしたオープンな研究コミュニティとともに発展しようとしているのが2026年度の特徴だと感じます。ただし、事業ドメインとフィジカルAIがマッチする企業は限られることも事実だと思っています。機械を始めとしたハードウェアを取り扱う、製造業や社会インフラ関係(通信や交通等)の企業を中心に、徐々に浸透していくような気がしています。
 
AIトレンド

まとめ

本コラムでは、2026年度のAIテクノロジートレンドとして、マルチエージェント・仕様駆動開発・ローカルLLMを活用したドメイン特化AI・フィジカルAIの4つをご紹介しました。
 
これらに共通するのは、「AIがより多くの技術的な処理を担うようになる」という方向性です。エージェントが自律的にタスクをこなし、仕様書からコードを生成し、特定ドメインの推論を行い、さらには現実世界で身体を動かすようになる。こうなってくると、エンジニアに求められるスキルセットも変わってくるのではないかと感じています(AIが生成したものをレビューするという観点では、これまでと同様に技術スキルは研鑽する必要があります)。
 
技術的な実装の詳細は、AIに委ねる部分が増える一方で、「何を作るべきか」「誰のどんな課題を解決するのか」を明らかにするプロセスの重要性はむしろ高まります。これはデザイン思考のアプローチそのものだと思っています。顧客へのヒアリング、課題の本質を掘り下げるための問いかけ、チームや顧客との合意形成といった、人間同士のコミュニケーションが、AIを活用した開発の成否を分ける鍵になっていくと考えています。
 
AIが得意なことはAIに任せ、人間は「何のためにそれを作るのか」を問い続けること。そのような役割分担が定着していく2026年度になるのではないでしょうか。引き続き、当社でも積極的に最新技術を取り入れながら、お客様の課題解決に取り組んでいきたいと思います。
 
以上、最後までお読みいただき、ありがとうございました。



当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。

エンジニアによるコラムやIDグループからのお知らせなどを
メルマガでお届けしています。

メルマガ登録ボタン


松尾 大輔

AIスマートソリューション部 テクニカルスペシャリスト

この執筆者の記事一覧

関連するソリューション

業務改革

AI

関連するナレッジ・コラム

通信は“運ぶ”から“考える”へ~AIネイティブネットワークで変わるインフラ運用

オブジェクト指向がAIデータ活用を変える?RAGの限界とエージェント×カプセル化の可能性

脅威レベルで整理する「生成AI開発のリスク」