BTABoKに基づくITアーキテクチャ策定における生成AI（LLM）/Agentic AI活用に関する考察

要旨（Abstract）

本稿は、Iasaが公開するBTABoK（Business Technology Architecture Body of Knowledge）を参照枠組みとして、情報システム開発におけるITアーキテクチャ策定活動を『価値』『人』『運用』『成果』の観点から整理し、生成AI（大規模言語モデル：LLM）および、知覚→推論→行動→学習の循環を持つAgentic AI（エージェンティックAI）が、どの工程で有効に機能しうるかを具体的な利用シーンとともに示します。さらに、BTABoKの4フェーズ（Imagine/Become/Achieve/Maximise）とAgentic AIの4サイクル（Perceive/Reason/Act/Learn）を対応付けた『BTABoK×Agentic AI対応マップ（筆者整理）』を提示し、導入時に不可欠となるガバナンス設計（責任境界・検証・監査可能性）を論じます。

キーワード

BTABoK, ITアーキテクチャ, 生成AI, 大規模言語モデル（LLM）, Agentic AI, エンゲージメントモデル, ガバナンス, 検証

１．はじめに

生成AI（大規模言語モデル：LLM）の普及により、要件解釈、意思決定資料の作成、設計レビュー、ドキュメント整備といった、アーキテクトの主要業務において、要約・分類・比較・文章化といった言語処理を業務へ組み込むことが現実的になってきました。一方で、LLMは確率的生成である以上、誤りや曖昧さを含む出力を返し得ます。そのため、アーキテクチャ策定に適用する際には、入力根拠の明示、検証プロセス、責任境界（RACI/権限）を運用設計として組み込むことが不可欠です。注²

本コラムでは、ITアーキテクトの知識体系であるBTABoK（Business Technology Architecture Body of Knowledge）を参照枠組みとして、情報システム開発におけるITアーキテクチャ策定プロセスの中で、LLMおよびAgentic AIが有効と思われる領域と具体的な利用シーンを整理します。

２．BTABoKの概要とエンゲージメントモデル（4フェーズ）

BTABoKのエンゲージメントフレームワークは、Deming/ShewhartのPDCAに基づく循環モデルとして4フェーズに分割され、Imagine（Digital Customer）→Become（Digital Business）→Achieve（Digital Employee）→Maximise（Digital Operations）として説明されます。注¹

また、エンゲージメントモデルは、中心にアーキテクチャロールを置き、その周囲に People / Value / Operating / Outcomes の4サブモデルを配置して、概念形成から価値実現までをライフサイクルとして扱います。注²

３．ITアーキテクチャ策定における生成AI（LLM）の有効領域

BTABoKの活動を『価値』『人』『運用』『成果』の観点で捉えると、LLMは特に次のような領域で効果を発揮します。

表1　BTABoK観点別：LLM活用タスク（例）

BTABoK観点	LLMに任せる作業（例）	アーキテクトが担う判断・検証
Value（価値）	価値仮説の言語化、ビジネスケースの要約、代替案の比較観点生成	投資対効果/リスク/制約の妥当性確認、意思決定責任
People（人）	ステークホルダー論点整理、コミュニケーション計画草案、役割定義案	利害調整、責任境界（RACI）の確定
Operating（運用）	要求/ASR抽出、トレーサビリティ表（RTM）草案、ADRドラフト、レビュー観点提示	要件の真正性、合意形成、設計トレードオフ最終判断
Outcomes（成果）	KPI候補抽出、測定設計案、運用データの要約/傾向分析	指標の有効性、組織目的との整合、改善施策の優先度

たとえば、Traceability（VM-T）は、ビジネスゴールからアウトカム、要求、意思決定へ価値を紐付けて追跡する方法として定義されています。注³

またRequirements（OM-R）では、要求をソースから最終アウトカムまで追跡し、RTMにより『満たす/満たさない』も含めて文書化することが求められます。注⁴

４．Agentic AI：知覚→推論→行動→学習サイクルと外部ツール連携

Agentic AIは、知覚（Perceive）→推論（Reason）→行動（Act）→学習（Learn）の循環を持ち、LLMを中核に外部ツール（検索、API、実行基盤など）と連携して、複数ステップのタスクを自律的に実行できる点が特徴です。一方、企業利用では『検証（validity）』—出力が要件・制約・規制・運用現実に照らして正しいこと—を担保する仕組みが成功要因となります。注⁸

５．BTABoK × Agentic AI対応マップ

BTABoKの4フェーズとAgentic AIの4サイクルを対応付けることで、各局面で『何を観測し、何を推論し、何を実行し、何を学習として残すか』を議論しやすくなります。注¹

表2　BTABoK × Agentic AI対応マップ

	知覚（Perceive）	推論 （Reason）	行動 （Act）	学習 （Learn）
Imagine（Digital Customer）	顧客/市民の課題信号収集（VoC/ログ/調査）	価値仮説・顧客旅程コンセプト評価	探索プロトタイプ情報収集の自動化（検索/RAG）	仮説検証結果の知識化（メモリ）次の探索へ
Become（Digital Business）	業務/能力の現状把握制約・前提収集	ビジネスケース代替案比較リスク整理	意思決定資料作成ロードマップ草案合意形成支援	KPI/指標の設計・更新判断基準の学習
Achieve（Digital Employee）	要求/ASR・ステークホルダー入力の観測	アーキ判断トレードオフ品質特性分析	設計成果物整備ADR/レビューテスト生成	利用状況・不具合傾向改善ループへ反映
Maximise（Digital Operations）	運用データ/変更要求監視・検知	影響分析優先度付けガードレール	自動化/DevOpsドキュ更新ツール実行	計測→改善技術的負債の最適化

６．具体的な利用シーン

（1）要求・制約・ASR抽出とトレーサビリティ

要件定義では、自然言語の要求からアーキテクチャ上重要な要求（ASR: Architecturally significant requirements）や制約を抽出し、ソース→要求→意思決定→成果物→測定指標へとトレース可能にすることが重要です。LLMは、会議メモ・RFP・既存仕様から要求候補を抽出し、要求分類（機能/非機能/制約/規制）や論点の抜け漏れチェックリストを生成できます。一方で、要求の真正性（誰が言ったか、合意されたか）と優先順位づけ・採否判断は、最終的に人間側が責任を持つ必要があります。注⁴

（2）代替アーキテクチャ案生成とトレードオフ分析

BTABoKでは、最初に提示された解が必ずしも最適とは限らない前提で、代替案比較と意思決定支援を重視します。LLMは、同一の要求集合に対して複数の構造案を提示し、品質特性（性能、可用性、セキュリティ、運用性など）の観点で差分を説明する用途に適します。ただし、品質特性のトレードオフは組織の優先度と制約に依存するため、結論はアーキテクトが根拠（測定計画・運用条件・規制等）とともに提示することが必要です。

（3）設計成果物（ADR/レビュー資料）自動整備と検証

設計の価値は図そのものではなく、なぜその判断に至ったか（理由・根拠・前提・代替案）にあります。LLMは、レビュー観点の体系化、アーキテクチャ決定の記録であるADR（Architecture Decision Record）への落とし込み、差分要約などの“文書化”に強みがあります。さらにAgentic AIとして、変更検知→影響範囲推論→関連ドキュメント更新→テスト/静的解析結果の取り込み、といった整合性維持を支援できます。注⁵

（4）運用データを用いた継続的改善（Measurement/Learn）

Maximise（Digital Operations）の局面では、運用監視データ、インシデント記録、問い合わせ、性能指標などが『知覚』の入力となります。Agentic AIは、異常兆候の要約、一次切り分けの支援、既知手順の提案、必要に応じたチケット起票などを連鎖的に実行できます。ただし、マルチステップのタスクでは誤りが複合化しうるため、重要操作の前段に検証と人間承認を置き、段階的に自動化範囲を拡張するのが実務的です。注⁷注⁸

７．ガバナンス設計（責任境界・検証・監査可能性）

Agentic AIは『行動（Act）』を伴うため、単なる文章生成よりもガバナンスの要求水準が上がります。そのため導入時には、(a)誰が何に責任を持つか（RACI）、(b)どの入力を根拠とするか（データ境界）、(c)どの検証を通過したら実行可能か（validity gate）、(d)監査可能なログ（入力・出力・差分・承認）をどこに残すか、をアーキテクチャとして明示する必要があります。注⁶注⁸

８．おわりに

BTABoKは、価値創出に結びつくアーキテクト活動を体系化し、個の実践を組織能力へ接続する枠組みです。生成AI/Agentic AIはその活動を加速し得ますが、LLM出力の不確実性を前提に、検証・承認・監査可能性を設計しなければ組織的リスクを増大させます。本稿の対応マップとサブモデル別整理を起点に、Iasa日本支部コミュニティで実践知（パターン／失敗学）を蓄積し、読者の現場に適用できる形で共有していくことが重要です。

ご一読いただきありがとうございました。Iasa日本支部では情報交換や勉強会の場を設けており、アーキテクチャの実践的な活動についても研鑽を深めていますので、今後のIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします。

脚注（BTABoK記載場所）

注1：BTABoK Engagement Frameworkの4フェーズ（Imagine/Become/Achieve/Maximise）とPDCA由来の循環モデルについて：  - Iasa Global, BTABoK Dictionary 2 - Framework – Outcome Phases and Outcome Spikes   https://iasa-global.github.io/btabok/dictionary.html#2---framework--outcome-phases-and-outcome-spikes - Iasa 日本支部  コラム, BTABoKが拓くアーキテクチャ実践の新時代   https://www.iasa-japan.org/post/new-era-of-architecture-practice

注2：エンゲージメントモデルがPeople/Value/Operating/Outcomesの4サブモデルで構成され、中心にアーキテクチャロールを置く構造について： -Iasa 日本支部  コラム, BTABoK Engagement Model（６）～エンゲージメントモデルでバリューストリームの実現を～ https://www.iasa-japan.org/post/valuestreamswithengagementmodels -Iasa Global. BTABoK Engagement Models   https://iasa-global.github.io/btabok/engagement_models_m.html

注3：Traceability（VM-T）の定義（価値をアーキテクチャ意思決定へ紐付けて追跡する）について： - Iasa Global, BTABoK Dictionary 6.5 - Traceability (VM-T):   https://iasa-global.github.io/btabok/dictionary.html

注4：Requirementsはソースからアウトカムまでトレースし、RTMで満たす/満たさないも含め文書化する点について： - Iasa 日本支部  コラム, BTABoK：Requirements ～ アーキテクチャ上重要な要求～    https://www.iasa-japan.org/post/btabok-requirements  - Iasa Global, BTABoK Requirements    https://iasa-global.github.io/btabok/requirements.html

注5：設計の価値は成果物そのものではなく、理由・根拠・トレードオフと要求へのトレーサビリティにある点について： - Iasa 日本支部  コラム,  BTABoK Design ～ デザイン（設計）とは何か ～  https://www.iasa-japan.org/post/btabok-design - Iasa Global, BTABoK Operating Model / Design   https://iasa-global.github.io/btabok/design.html

注6：ガバナンス（OM-G）が役割責任、意思決定、標準の監視、証跡（evidence）等を含む点について： - Iasa 日本支部  コラム, BTABoK 　Governance　～ガバナンスとアーキテクチャ～ https://www.iasa-japan.org/post/btabok-governance - Iasa Global. BTABoK Governance   https://iasa-global.github.io/btabok/governance_em.html

注7：MeasurementがKPIを識別しライフサイクルを通じて追跡する点について：  - Iasa Gloval, BTABoK Dictionary 3 - Outcome Spikes    https://iasa-global.github.io/btabok/dictionary.html#3---outcome-spikes

注8：Agentic AIの本質を「検証（validity）」とし、基盤モデル性能よりアプリケーションレベルの検証プロセスが重要という観点： - Chamudi Ezzat, Agentic AIの本質は「検証」である、大規模言語モデルはあくまで選択肢の一つ   https://qiita.com/chamudi/items/10645a56e4709f2b6322

参考文献

- Iasa Global: Business Technology Architecture Body of Knowledge (BTABoK) https://iasa-global.github.io/btabok/

- Iasa Global, BTABoK Engagement Model / Dictionary https://iasa-global.github.io/btabok/tag_engagement_model.html

- Iasa日本支部 コラム, アジャイル型システム開発におけるBTABoKの活用について https://www.iasa-japan.org/post/utilizing-btabok-in-agile-system-development

- Chamudi Ezzat: 「Agentic AIの本質は『検証』である」（Qiita, 2025-11-03 https://qiita.com/chamudi/items/10645a56e4709f2b6322