本記事では、DXの「次の段階」として注目されるAX(Agentic Transformation:エージェント変革)について、Gartnerや経済産業省などの一次情報をもとに解説します。「40%以上のプロジェクトが中止される」という厳しい予測を乗り越えるための設計思想と、具体的な実装ロードマップをお伝えします。
なお本記事では、GXOとして「AIエージェントが判断から実行まで担う企業変革」を便宜上AX(Agentic Transformation)と呼び、既存のDX議論を補完する整理として提示します。
1. DXの限界とAXの必要性
DXレポートが指摘し続けてきた課題
経済産業省が2022年に公表した「DXレポート2.2」では、多くの企業がDX推進に取り組んでいる一方で、デジタル投資の内訳は**「既存ビジネスの維持・運営に約8割が占められている状況が継続」**していると指摘されています。1
つまり、DXの取り組み自体は進んでいても、投資が「効率化」に偏り、「収益向上」や「企業変革」にはつながっていないケースが多いのです。同レポートでは「デジタルを、省力化・効率化ではなく、収益向上にこそ活用すべき」と明確に述べられています。1
DXからAXへ—「System of Record」から「System of Action」へ
ここで注目したいのが、AX(Agentic Transformation)という考え方です。
DXが「データを整える」「業務をデジタル化する」段階だとすれば、AXは「整えたデータとデジタル基盤を使って、AIが実際に行動する」段階です。言い換えれば、DXは「System of Record(記録のシステム)」を作る取り組みであり、AXは「System of Action(行動のシステム)」を作る取り組みです。
DXで整備した基盤の上に、AIエージェントが「判断」し「実行」する仕組みを載せる——これがAXの本質です。
章末サマリー
DXは進んでいるが、投資の8割は効率化に偏り、収益向上に直結していない1
AXは「記録のシステム」から「行動のシステム」への進化を意味する
DX基盤の上にAIエージェントが判断・実行する仕組みを載せるのがAX
2. まず誤解を解く—チャットボット・RPA・AIエージェント・エージェント型AIの違い
用語の混乱と「エージェントウォッシング」問題
「AIエージェント」という言葉が急速に広まる中、市場では用語の混乱が生じています。Gartnerは2025年5月に「AIエージェントとエージェント型AIに関する見解」を発表し、この混乱について整理しています。2
さらに問題なのは、「エージェントウォッシング」と呼ばれる現象です。これは、既存のチャットボットやRPAを「AIエージェント」とリブランディングして販売する行為を指します。Gartnerによれば、数千存在するエージェント型AIベンダーのうち、実際にエージェント機能を持つのは約130社程度とされています。3
Gartnerによる定義の整理
Gartnerは、それぞれの技術を以下のように区別しています。2
チャットボット あらかじめ定義されたルールやスクリプトに基づいて応答するシステム。ユーザーの入力に対して決まった反応を返すが、自律的な判断や行動は行わない。
RPA(ロボティック・プロセス・オートメーション) 事前に定義された手順を自動で実行するツール。人間が行う定型的な操作(クリック、コピー、入力など)を再現するが、状況に応じた判断は行わない。
AIエージェント デジタルおよびリアルの環境で、状況を知覚し、意思決定を下し、アクションを起こし、目的を達成するためにAI技法を適用する自律的または半自律的なソフトウェア。
エージェント型AI(Agentic AI) 組織のために行動し、自律的に意思決定を下してアクションを起こすために、組織に代わって行動する権利を付与された、目標主導型のソフトウェア・エンティティ。記憶、計画、センシング、ツール利用、ガードレールなどのコンポーネントと共にAI手法を使用して、タスクを完了し、目標を達成する。
段階的な進化の理解
Gartnerの説明によれば、現在の多くのAIエージェントは「手組み細工的な存在」であり、ある程度の判断力を持ちシンプルなタスクを自律的に実行できます。一方、新世代のエージェント型AIは「エージェント性と目標指向性を備えた進化系」であり、記憶や計画、ツール活用などの機能を備え、複雑なタスクを目的指向で遂行することが期待されています。2
重要なのは、「AIエージェント」と「エージェント型AI」の境界線は曖昧であり、多くの場合、連続的に進化していくという点です。
章末サマリー
市場では「エージェントウォッシング」が横行しており、真の機能を持つベンダーは約130社程度3
チャットボット→RPA→AIエージェント→エージェント型AIと、自律性・目標指向性が段階的に向上2
現在のAIエージェントは「手組み細工的」だが、エージェント型AIへと進化しつつある
3. AXで何が変わるのか(具体例)
「回答する」から「実行する」へ
AXの本質は、AIが「回答」で終わらず「実行」まで行うことにあります。具体的な業務シーンで比較してみましょう。
カスタマーサポート
従来(DX段階) | AX実装後 |
|---|---|
問い合わせに対してFAQを検索し回答案を提示 | 回答だけでなく、返金処理・予約変更・配送ステータス更新まで自動実行 |
オペレーターが確認して実行 | 承認ルールに基づき自律的に処理、例外時のみ人間にエスカレーション |
営業支援
従来(DX段階) | AX実装後 |
|---|---|
メールの下書きを生成 | 顧客データ分析→見積作成→稟議申請→CRM更新まで一連の流れを実行 |
担当者が確認・修正・送信 | 担当者は最終確認のみ、定型案件は自動処理 |
経理業務
従来(DX段階) | AX実装後 |
|---|---|
仕訳の提案を表示 | 証憑の照合→例外判定→仕訳登録→支払申請まで実行 |
経理担当者が確認して入力 | 不明点のみ担当者に確認、それ以外は自動処理 |
ポイントは「判断」と「実行」の両立
従来のRPAは「決められた手順を正確に繰り返す」ことが得意でしたが、「状況に応じて判断する」ことは苦手でした。一方、生成AIは「判断」や「提案」は得意ですが、「実際に外部システムを操作して実行する」機能は持っていませんでした。
AIエージェントは、この両方を組み合わせることで、「状況を判断しながら、実際にアクションを起こす」ことを可能にします。
章末サマリー
AXでは「回答・提案」にとどまらず「実行」までAIが担う
カスタマーサポート、営業、経理など幅広い業務で適用可能
「判断力(生成AI)」と「実行力(ツール連携)」の組み合わせが核心
4. AXの技術要素—ツール連携とワークフロー設計
ツール連携(Function Calling / Tool Use)が中核
AIエージェントが「実行」できる理由は、外部システムを操作する「ツール」を呼び出せるからです。OpenAIのFunction CallingやAnthropicのTool Useといった機能により、AIモデルが「このAPIを呼び出して、このパラメータで実行する」という判断を行えるようになりました。4
例えば、顧客からの「返金してほしい」というリクエストに対して、AIエージェントは以下のような処理を行います。
会話の意図を理解(返金リクエスト)
必要な情報を確認(注文番号、返金理由)
返金ポリシーに照らして判断
返金処理APIを呼び出し
CRMに記録を更新
顧客に完了通知を送信
この一連の流れを、人間の介入なしに(または最小限の承認で)実行できることがAIエージェントの強みです。
ワークフローとエージェントの使い分け
Anthropicは「Building Effective Agents」という技術資料の中で、「ワークフロー」と「エージェント」を明確に区別しています。5
ワークフロー LLMとツールが事前に定義されたコードパスに沿って連携するシステム。予測可能性と一貫性が高く、明確に定義されたタスクに適している。
エージェント LLMが自らのプロセスとツール使用を動的に制御するシステム。柔軟性とモデル主導の意思決定が求められる場合に適している。
実務においては、すべてを自律的なエージェントに任せるのではなく、業務の性質に応じてワークフローとエージェントを使い分けることが重要です。定型的で例外の少ない業務はワークフローで、複雑で状況判断が必要な業務はエージェントで——という設計が現実的です。5
主要なプラットフォームと選択肢
現在、企業がAIエージェントを実装する際の主要な選択肢には以下があります。
Microsoft Copilot Studio:Microsoft 365やDynamicsと連携した自律型エージェントの構築
Amazon Bedrock Agents:AWS上でのエージェント構築、企業データとの統合
OpenAI API(Function Calling等):ツール呼び出し機能を活用したカスタムエージェント開発
LangChain / LangGraph:オープンソースのエージェント構築フレームワーク
どのプラットフォームを選ぶにせよ、重要なのは「自社の既存システムとどう連携させるか」「どこまでをAIに任せ、どこで人間が判断するか」という設計です。
章末サマリー
ツール連携(Function Calling等)により、AIが外部システムを操作可能に4
「ワークフロー」(予測可能な処理)と「エージェント」(動的な判断)を使い分ける5
プラットフォーム選定よりも、連携設計と権限設計が重要
5. 失敗パターン—なぜ40%以上が中止されるのか
Gartnerの予測:40%以上のプロジェクトが中止
Gartnerは2025年6月、**「2027年末までにエージェント型AIプロジェクトの40%以上が、コストの高騰、ビジネス価値の不明確さ、不十分なリスク・コントロールを理由に中止される」**という予測を発表しました。3
この予測は衝撃的ですが、同時に「どうすれば失敗を避けられるか」を考えるヒントを与えてくれます。
失敗パターン1:ユースケースが曖昧
Gartnerのアナリストは「現在のエージェント型AIプロジェクトの多くは、ハイプ(誇大な期待)に駆り立てられた初期段階の実験やPoCであり、しばしば誤った適用がなされている」と指摘しています。3
よくある失敗は、「AIエージェントを導入すること」自体が目的化してしまい、「何を解決したいのか」「どのKPIを改善したいのか」が曖昧なままプロジェクトが進むケースです。
失敗パターン2:権限・責任設計がない
AIエージェントが自律的に「実行」するということは、その結果に対する責任も発生するということです。「誰がAIに実行権限を与えたのか」「AIの判断が間違っていた場合、誰が責任を取るのか」——この設計がないまま導入を進めると、本番運用で問題が発生した際に対応できません。
失敗パターン3:ガードレール不足
エージェント型AIには、その自律性ゆえのリスクがあります。OWASP(Open Worldwide Application Security Project)は「Top 10 for LLM Applications(Version 2025)」において、プロンプトインジェクション(悪意ある入力によるAIの誤動作)、機密情報の漏洩、過剰な権限付与(Excessive Agency)などのリスクを警告しています。6
適切なガードレール(安全装置)なしにエージェント型AIを運用すると、セキュリティインシデントやコンプライアンス違反のリスクが高まります。
失敗パターン4:データ・連携基盤が弱い
AIエージェントは、外部システムを操作する「ツール」があってはじめて機能します。しかし、多くの企業では既存システムのAPI化が進んでおらず、AIエージェントが「実行したくてもできない」状態に陥ります。
DXの段階でシステム連携基盤を整備していないと、AXへの移行が困難になります。
章末サマリー
40%以上のプロジェクトが「コスト高騰」「価値不明確」「リスク管理不足」で中止予測3
失敗の主因は、ユースケースの曖昧さ、権限設計の欠如、ガードレール不足、連携基盤の弱さ
技術選定の前に、業務設計とガバナンス設計が必要
6. AXに必須のガバナンス設計
AIリスク管理の国際的フレームワーク
エージェント型AIを安全に運用するためには、体系的なリスク管理が必要です。参考となる国際的なフレームワークを紹介します。
NIST AI RMF 1.0(AI Risk Management Framework)
米国国立標準技術研究所(NIST)が策定したAIリスク管理フレームワークです。7 AIシステムの信頼性を高めるための原則として、「有効かつ信頼性がある」「安全である」「セキュアで復旧力がある」「説明責任を果たせる」「透明性がある」「説明可能である」「プライバシーが保護されている」「公平であり有害なバイアスが管理されている」といった特性を挙げています。
ISO/IEC 42001(AIマネジメントシステム)
AIシステムの開発・提供・使用に関する国際標準規格です。8 組織がAIを責任を持って管理するための枠組みを提供しています。
OWASP Top 10 for LLM Applications(Version 2025)
LLM(大規模言語モデル)特有のセキュリティリスクを整理したガイドラインです。6 プロンプトインジェクション(LLM01)、機密情報の開示(LLM02)、サプライチェーンリスク(LLM03)、データとモデルの汚染(LLM04)、不適切な出力処理(LLM05)、過剰な権限付与(LLM06)など、エージェント型AIを運用する際に注意すべきリスクが網羅されています。
実務で押さえるべき3つの柱
これらのフレームワークを実務に落とし込むと、以下の3つの柱が重要になります。
1. 権限管理
AIエージェントに「何を」「どこまで」実行させるかを明確に定義
承認が必要なアクションと、自動実行可能なアクションを区分
権限の付与・変更・取り消しのプロセスを整備
2. 監査ログ
AIエージェントが行った判断と実行の記録を保持
問題発生時に原因を追跡できる仕組み
定期的なログレビューと異常検知
3. 評価・改善
AIエージェントの判断精度を継続的に測定
誤判断や失敗ケースからの学習
定期的なレッドチーミング(攻撃者視点でのテスト)
章末サマリー
実務では「権限管理」「監査ログ」「評価・改善」の3つの柱を整備
ガバナンス設計なしのAX導入は、セキュリティ・コンプライアンスリスクを高める
7. エージェント標準化の動向—相互運用への潮流
標準化が進む背景
AIエージェントの普及に伴い、異なるベンダーやプラットフォーム間での「相互運用性」が課題として浮上しています。企業が複数のAIエージェントを導入する際、それぞれが独自のプロトコルで動作していては、統合管理が困難になるためです。
MCP(Model Context Protocol)とA2A(Agent-to-Agent)
ここまで読んで
「うちも同じだ」と思った方へ
課題は企業ごとに異なります。30分の無料相談で、
御社のボトルネックを一緒に整理しませんか?
営業電話なし オンライン対応可 相談だけでもOK
この課題に対応するため、業界では標準化の動きが加速しています。
MCP(Model Context Protocol) Anthropicが2024年11月25日に発表したオープンスタンダードで、AIエージェントと外部ツール・データソースとの連携を標準化するものです。9 これにより、異なるLLMでも同じツール定義を使い回せるようになります。発表から1年で、Claude、ChatGPT、Microsoft Copilot、Gemini、VS Code、Cursorなど主要プラットフォームに採用され、事実上の業界標準となっています。
A2A(Agent-to-Agent Protocol) Googleが2025年4月9日にGoogle Cloud Next '25で発表したオープンプロトコルで、複数のAIエージェント同士が連携するための通信規約を定めています。10 発表時点で50社以上のパートナー(Atlassian、Salesforce、SAP、ServiceNow等)が参加を表明し、2025年6月にはLinux Foundationに寄贈されました。
業界横断の標準化イニシアチブ
2025年12月9日、Linux Foundationは「Agentic AI Foundation(AAIF)」の設立を発表しました。11 Anthropic、OpenAI、Blockが共同設立者となり、MCPやOpenAIの「AGENTS.md」、Blockの「goose」といったプロジェクトが寄贈されています。AWS、Google、Microsoft、Bloomberg、Cloudflareなどもプラチナメンバーとして参加しており、業界を挙げた標準化の動きが本格化しています。
この標準化の流れは、企業にとって朗報です。特定のベンダーに依存せず、自社のニーズに最適なエージェントを組み合わせて活用できる可能性が広がっています。
章末サマリー
AIエージェントの相互運用性が課題として浮上
MCP(Anthropic)やA2A(Google)など、標準化プロトコルが登場
業界横断の協業により、ベンダーロックイン回避の環境が整備されつつある
8. 実装ロードマップ—段階的なAX導入の進め方
AXは「概念」ではなく「実装計画」で考える
AXを成功させるためには、抽象的な議論を超えて、具体的な実装計画に落とし込む必要があります。以下に、段階的なロードマップを示します。
Phase 0:業務棚卸(2〜4週間)
目的:AXを適用すべき業務を特定する
やること
現状の業務フローを可視化
「判断」と「実行」が発生するポイントを洗い出し
例外処理のパターンを整理
成功を測るKPIを定義(処理時間、エラー率、顧客満足度など)
アウトプット
業務フロー図(判断ポイント・実行ポイント付き)
AX適用候補リスト(優先度付き)
KPI定義書
Phase 1:設計(3〜6週間)
目的:権限・責任・監査の設計を行う
やること
AIエージェントに付与する権限の定義
自動実行できる範囲と、人間の承認が必要な範囲の線引き
責任分界点の明確化(法務・セキュリティ部門との合意形成)
監査ログの設計(何を、いつ、どの粒度で記録するか)
アウトプット
権限マトリクス
承認フロー設計書
監査ログ仕様書
Phase 2:ツール化(4〜8週間)
目的:AIエージェントが操作できる「ツール」を整備する
やること
既存システムのAPI化(または既存APIの整理)
ツール定義の作成(入力パラメータ、出力形式、エラーハンドリング)
認証・認可の設計
テスト環境の構築
アウトプット
API仕様書
ツール定義ファイル
テスト環境
Phase 3:ガードレール実装(2〜4週間)
目的:安全に運用するための防護策を実装する
やること
入力バリデーション(プロンプトインジェクション対策)6
出力フィルタリング(機密情報漏洩対策)
レート制限(異常動作の検知と停止)
承認ワークフローの実装
ログ収集・可視化基盤の構築
アウトプット
ガードレール実装コード
監視ダッシュボード
アラートルール
Phase 4:パイロット運用(4〜8週間)
目的:限定的な範囲で実運用し、問題を洗い出す
やること
少数のユーザー・少量のトランザクションで試験運用
判断精度の測定と改善
例外ケースの収集と対応策の検討
運用手順書の整備
アウトプット
パイロット結果レポート
改善リスト
運用手順書
Phase 5:本番展開とOps(継続)
目的:本格運用と継続的改善
やること
段階的な適用範囲の拡大
継続的なモニタリングと改善
新たなユースケースの発掘と適用
定期的なレビューと見直し
アウトプット
運用レポート(週次/月次)
改善提案書
次期計画
章末サマリー
AXは5つのPhaseで段階的に実装する
Phase 0-1(業務棚卸・設計)が最も重要——ここで権限と責任を明確化
技術実装(Phase 2-3)の前に設計を固めることで、手戻りを防ぐ
9. まとめ—AXで「動く仕組み」を作る
DXとAXの関係
DXとAXは対立する概念ではなく、連続した進化です。DXで整備したデータ基盤・システム連携基盤があってこそ、AXは機能します。「DXができていないのにAXを」という順番は成り立ちません。
一方で、DXだけでは「業務が自走する」状態にはなりません。人間がシステムを操作し、判断し、実行する——この構図のままでは、人材不足の解消や生産性の飛躍的向上は難しいでしょう。
成功するAX導入の3つのポイント
1. AIモデル選定より「設計」が先
どのLLMを使うか、どのプラットフォームを選ぶかよりも、「何を自動化するか」「誰がどこまで責任を持つか」「どう監査するか」という設計が重要です。設計が曖昧なまま技術選定を進めると、後から大きな手戻りが発生します。
2. ツール連携が「心臓部」
AIエージェントの実行力は、連携できるツール(API)の質と量で決まります。既存システムのAPI化や、認証・認可の整備がボトルネックになりがちです。DXの段階でシステム連携基盤を整備しておくことが、AX成功の鍵になります。
3. 運用が「本番」
AXは「作って終わり」ではありません。AIエージェントの判断精度は継続的に改善する必要がありますし、新たなリスクや例外ケースへの対応も求められます。構築プロジェクトの完了は、運用のスタートにすぎません。
GXOの無料相談(30分)でわかること
GXOでは、AX導入を検討されている企業様に対して、30分の無料相談で以下を整理いたします。
無料相談で提供するアウトプット
項目 | 内容 |
|---|---|
AX適用候補 業務トップ3 | 貴社の業務から、AX効果が高い領域を特定 |
権限/承認の線引き案 | どこまで自動化し、どこで人間が判断するかの初期設計 |
必要なAPI・連携棚卸(概算) | 既存システムとの連携ポイントを洗い出し |
3ヶ月パイロット計画(ラフ) | 最初の一歩として何から始めるかのロードマップ |
GXOの強み
要件定義から運用保守まで一貫:設計だけでなく、実装・運用までワンストップで支援
システム連携基盤構築:既存システムのAPI化、認証基盤整備の実績
段階的リリース支援:パイロット運用から本番展開までの伴走
「AIエージェント、興味はあるけど何から始めればいいかわからない」という方も、まずはお気軽にご相談ください。
10. FAQ
Q1. DXが完了していないとAXは導入できませんか?
A1. DXの「完了」を待つ必要はありませんが、一定の基盤は必要です。具体的には、AIエージェントが連携する対象システムにAPIアクセスできること、業務データがデジタル化されていることが前提となります。すべてのDXが完了していなくても、特定の業務領域でAXを先行導入し、成果を出しながらDXを加速させるアプローチも有効です。
Q2. AIエージェントの判断ミスで問題が起きた場合、責任は誰にありますか?
A2. 責任分界は、権限設計・承認フロー・社内規程・委託契約の設計に依存します。一般に「自動実行の権限付与」はガバナンス上の重要意思決定となるため、法務・セキュリティ部門と合意した責任分界を文書化した上で運用することが推奨されます。具体的な責任範囲は、個社の規程・契約によって異なるため、導入前に法務確認を行うことをお勧めします。
Q3. セキュリティリスクが心配です。どう対策すべきですか?
A3. OWASP Top 10 for LLM Applications(Version 2025)6を参考に、プロンプトインジェクション対策(入力バリデーション)、機密情報漏洩対策(出力フィルタリング)、過剰権限対策(最小権限の原則)を実装します。加えて、監査ログの取得、異常検知、定期的なレッドチーミング(攻撃者視点でのテスト)を運用に組み込むことが重要です。
Q4. どの業務からAXを始めるべきですか?
A4. 「判断のパターンが明確」「実行の頻度が高い」「ミスのコストが比較的低い」業務から始めることをお勧めします。例えば、社内問い合わせ対応、定型的な経費精算、在庫補充のアラートなどが候補になります。逆に、顧客への直接的な金銭支払いや、法的判断が伴う業務は、十分な実績を積んでからの適用が賢明です。
Q5. 導入コストと期間の目安を教えてください
A5. 業務の複雑さと連携システムの状況によりますが、パイロット導入(1業務領域)で3〜6ヶ月程度が一つの目安です。コストは、既存システムのAPI化状況によって大きく変わります。すでにAPI基盤がある場合は比較的低コストで始められますが、レガシーシステムの改修が必要な場合は追加投資が必要です。まずは無料相談で概算をお出しすることをお勧めします。
Q6. RPAと共存できますか?どう棲み分けますか?
A6. RPAとAIエージェントは共存可能であり、棲み分けが重要です。RPAは「ルールが明確で例外がほぼない定型作業」に適しており、AIエージェントは「状況に応じた判断が必要な業務」に適しています。例えば、データ入力のような単純作業はRPA、問い合わせ対応のような判断を伴う作業はAIエージェント、というように業務特性で使い分けます。
Q7. 評価指標は何が妥当ですか?
A7. AXの評価指標は、業務KPIとAI性能指標の両面で設定します。業務KPIとしては「処理時間」「エラー率」「顧客満足度」「コスト削減額」など。AI性能指標としては「判断精度」「人手介入率」「例外発生率」「ガードレール発動率」などが有効です。パイロット段階で指標を定義し、継続的にモニタリングすることが重要です。
Q8. ログは何を残すべきですか?
A8. 監査・改善の観点から、以下の4種類のログを残すことを推奨します。①プロンプトログ(AIへの入力内容)、②ツール呼び出しログ(どのAPIを、どのパラメータで呼び出したか)、③判断根拠ログ(参照したルール・ナレッジ・入力要因・実行したツールを説明可能な形で要約。機微情報を含めない設計が前提)、④承認履歴ログ(人間の承認・却下の記録)。これらを保持することで、問題発生時の原因追跡と、継続的な精度改善が可能になります。ログの保持期間は、業界規制やコンプライアンス要件に応じて設定してください。
出典一覧
経済産業省「DXレポート2.2(概要)」(2022年7月)https://www.meti.go.jp/policy/it_policy/dx/002_05_00.pdf ↩ ↩2 ↩3
Gartner「AIエージェントとエージェント型AIに関する見解を発表」(2025年5月14日)https://www.gartner.co.jp/ja/newsroom/press-releases/pr-20250514-ai-agent ↩ ↩2 ↩3 ↩4
Gartner "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027"(2025年6月25日)https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027 日本語版:Gartner「2027年末までに過度な期待の中で生まれるエージェント型AIプロジェクトの40%以上が中止されるとの見解を発表」(2025年6月25日)https://www.gartner.co.jp/ja/newsroom/press-releases/pr-20250625-agentic-ai-project ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7
OpenAI "Function calling" https://platform.openai.com/docs/guides/function-calling ↩ ↩2
Anthropic "Building Effective Agents"(2024年12月19日)https://www.anthropic.com/engineering/building-effective-agents ↩ ↩2 ↩3
OWASP "Top 10 for Large Language Model Applications" https://owasp.org/www-project-top-10-for-large-language-model-applications/ ↩ ↩2 ↩3 ↩4 ↩5
NIST "AI Risk Management Framework (AI RMF 1.0)" 日本語版 https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.jpn.pdf ↩ ↩2
ISO/IEC 42001:2023 - AI management systems https://www.iso.org/standard/42001 ↩ ↩2
Anthropic "Introducing the Model Context Protocol"(2024年11月25日)https://www.anthropic.com/news/model-context-protocol ↩
Google Developers Blog "Announcing the Agent2Agent Protocol (A2A)"(2025年4月9日)https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/ ↩
Linux Foundation "Linux Foundation Announces the Formation of the Agentic AI Foundation"(2025年12月9日)https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation ↩
「やりたいこと」はあるのに、
進め方がわからない?
DX・AI導入でつまずくポイントは企業ごとに異なります。
30分の無料相談で、御社の現状を整理し、最適な進め方を一緒に考えます。
営業電話なし オンライン対応可 相談だけでもOK



