検索結果

今回のコラムではBTABoKのPeople ModelでとりあげられているCommunityにおける内部コミュニティと外部コミュニティについての考え方を示しながら、Iasa日本支部におけるコミュニティ活動を紹介していきたいと思います。 　 BTABoKのPeople Model／CominityではIasaＧlobalの考える組織やコミュニティのあり方を述べており、BTABoKの記述の中でも、理解を深めておくべきところであると考えます。 　以下BTABoKの日本語訳を示すとともに、筆者の見解を加えていきます。 ↓↓↓↓↓↓↓↓↓↓　以下　BTABoK原文（翻訳）↓↓↓↓↓↓↓↓↓↓　 コミュニティとは何か 　BTABoKでは「コミュニティ」という用語を、 組織の内部および外部の拡張チームメンバーのグループ を指し、最良のビジネスおよび技術戦略を実現するために協力しなければならないことを指しています。 　コミュニティはアーキテクトたちを結びつける存在であり、それを卓越性の中心地やプロフェッショナルの拠点、あるいはその他の言葉で呼ぶ人もいるかもしれません。 　アーキテクチャコミュニティの目的は、共有するコンテキスト、範囲、対象領域に影響を与えるアーキテクチャ能力全体を向上させるとともに、コミュニティ自身および組織のために設定した目標を達成することにあります。 　さらに、アーキテクチャコミュニティはアーキテクト内部のコミュニティだけでなく外部コミュニティも含め、専門的実践の卓越性の中心地にもなっています。 ↑↑↑↑↑↑↑↑↑↑　以上　BTABoK　原文（翻訳）　↑↑↑↑↑↑↑↑↑↑   　 拡張チーム（Extended Team）とは、正式なアーキテクチャチームの枠組みを超えて、アーキテクチャ活動を実践する組織です。企業などで組織を越えたワーキングチームを作ったり、個人的に外部のコミュニティに参加してチームとして活動することでアーキテクチャ能力を高めることが出来ます。 　ここで述べられている 外部コミュニティのひとつが、Iasa日本支部 でもあり、アーキテクトの皆さんに貢献すべく、日々活動を続けています。 具体的な活動では、 「エンタープライズアーキテクチャ実践についての情報交換の場」 「ビジネスアーキテクトへの道を目指す研鑽の場」 「若手アーキテクトへの啓蒙の場」 などがあり、それぞれが着実に活動を行って参りました。 　IASA日本支部では、２０２６年度においてもこれらのコミュニティをより多くのアーキテクトに参加いただけるよう体制を準備しております。   それでは、BTABoKにおけるコミュニティについての目的や活動の進め方などを以下に示していきます。 ↓↓↓↓↓↓↓↓↓↓　以下　BTABoK原文（翻訳）↓↓↓↓↓↓↓↓↓↓　 なぜコミュニティが重要なのか 　BTABoKでは、「コミュニティ」という用語を、単なる緩やかな人々の集まりではなく、組織内および組織とつながりのある専門家集団（ベンダーやサービスプロバイダーを含む）を指すものとして用いています。 BTABoKの信条 　以下の信条はBTABoK全体におけるコミュニティへの基本的なアプローチを説明しています。 机上のフレームワークは、現場のコミュニティには敵わない 　BTABoKはアーキテクト実務における真のプロフェッショナルモデルに基づいて構成されています。このモデルは、フレームワークやプロセスに単に従うのではなく、自分の仕事に完全に責任を持つ質の高い人材を育成することを目的としています。コミュニティは、アーキテクト能力を最大限に提供するための基盤となります。 専門分野に基づく対立が実践を破壊する 　アーキテクチャ業務を発展させるには、「アーキテクト」という肩書きを持つ人々と、その業務に共感する人々（肩書きの有無にかかわらず）が協力して、実用的なエンゲージメントモデルを構築する必要があります。そうしなければ、実践全体の価値を失うリスクを負うことになります。このリスクは、「アーキテクチャ」という用語の使用、そしてステークホルダーコミュニティと組織の戦略におけるその認識に関連しています。 　例えば、ビジネスアーキテクトとソフトウェアアーキテクトやソリューションアーキテクトが分断されていたり、意見が対立したりする場合、アーキテクチャ業務全体の主目的を達成するために必要なバリューストリーム（アーキテクチャ）に断絶が生じます。 　さらに、アーキテクチャ業務の全体的な価値、目的、ミッションについて、ステークホルダーはあまりにも多くの定義やニュアンスが提供されると混乱してしまいます。多多くの場合、この混乱は、アーキテクチャ・プラクティスに対する全体的な不満へと発展し、さらに悪い場合には、アーキテクチャ・プラクティスの一部または全体が価値を提供していないという認識に至る可能性があります。 コミュニティがアーキテクチャを定義する 　前の原則を一歩進めて考えると、アーキテクトのコミュニティ（拡張チームを含む）そのものが、良くも悪くも組織のアーキテクチャを形づくっていると言えます。コミュニティには、専門分野、影響範囲、ドメイン領域に関係なくすべての実務者、拡張 チーム (肩書きを持たないアーキテクチャを実践する者)、および内部組織の関係者に影響を与えるベンダーやサービススタッフが含まれます。 　このコミュニティが、自らの関わり方のモデルをうまく示し、実践の具体的な姿を明確にし、個々のスキルを高め、さらにステークホルダーとの関係を適切にマネジメントできていれば、アーキテクチャは組織にとって価値あるものとして認識されるようになります。そして、その価値が認められるかどうかの最大の課題は、外部ではなく、実はこの実践の内部にあります。 自分の価値を積極的に見極めましょう 　アーキテクトコミュニティの提供する価値（価値提案）は、明確かつ客観的に定量化するのが難しいものです。コミュニティが価値提案を推進するために利用できる主要な要素は三つあります。これらは組織のアーキテクチャに対する見方を劇的に変える重要な要素です。 BTABoKのステークホルダー主導のアプローチを活用してください。価値とは認識によって決まるものです。組織がそう信じていることが、事実かどうかにかかわらず、その組織にとっての“真実”となります。一般的に、1人のアーキテクトにつき3〜5人程度、アーキテクチャ実践において非常に重要なステークホルダーが存在し、その多くは互いに重なり合っています。これらのステークホルダーがチームに価値を感じていれば、そのチームは価値あるものとして認識されます。受け身ではなく、主体的に動くこと。提供されているツールを活用してステークホルダーを適切に分担し、彼らの業務に貢献していくことが重要です。 ガバナンス重視や協議的な目標ではなく、革新的でオーナーシップに基づく目標を設定しましょう。価値ある実践の目標は、どのような価値が提供され、どのステークホルダーに、どのように測定されるかに焦点を当てるべきです。再利用、コスト削減、リスク回避は企業の安定性に焦点を当てています。イノベーションは新規ビジネス、高いリターン、新規顧客、成功したミッション、迅速なサービスなどに基づいています。オーナーシップベースの目標は、設計ではなく提供に重点を置いています。各メンバーやメンバーチームがこの実践からどれだけの成功した成果を生み出したのでしょうか? エンゲージメントモデルについて明確にしましょう。 ここでいうエンゲージメントとは、アーキテクトが当該プラクティスをどのように認識し、いかなる方法でサービス提供を行うかに関する在り方を指します。 社内のすべてのアーキテクトが関与し、エンゲージメントモデルを承認すれば、彼らはそれを実装し、実践します。これにより、価値提供における議論や意見の相違、摩擦が減ります。チーフアーキテクトがアプローチを決めるのを待たないでください。専門的な実践には、参加者同士の明示的な合意(暗黙の合意ではない)が含まれます。以下のアプローチは、あらゆるタイプとレベルのアーキテクトで構成されるエンゲージメント運営委員会の設立に役立ちます。 ↑↑↑↑↑↑↑↑↑↑　以上　BTABoK　原文（翻訳）　↑↑↑↑↑↑↑↑↑↑   　ここまでは、アーキテクトにとってのコミュニティの意義を述べています。BTABoKでは、それぞれのアーキテクトが現場で十分に活躍できることを重視しており、そのことが実現できる環境となるコミュニティにすることを提案しています。 　Iasa日本支部のコミュニティ活動においても、メンバーが対等に議論し、互いに学び合い研鑽することにより、多くの仲間が共有できる成果を生み出せることを目指しています。 　 　次に、BTABoKはどのようにコミュニティを形成し、価値を生み出すかについての取り組みを述べています。   ↓↓↓↓↓↓↓↓↓↓　以下　BTABoK原文（翻訳）↓↓↓↓↓↓↓↓↓↓　 コミュニティアプローチ 　BTABoKは「コミュニティ」という用語を、医師、建築士、その他の知識・能力に基づく専門職が用いる専門職モデルをある程度模倣した厳格な実践モデルを指すために用いています。 実践コミュニティとセンター・オブ・エクセレンス（CoE） 単に「コミュニティ」という言葉を使うのではなく、組織はそれを実践のコミュニティや集約された知見の中心（CoE）と考えるべきです。このようにコミュニティを発展させることで、コミュニケーションや知識の共有、そしてチーム全体の責任感や共通の目標の意識が大幅に向上します。 成果を達成するためのコミュニティの構築 　アーキテクトコミュニティの体制構築には、a) 組織への報告、b) 役割と実践におけるリーダーシップという2つの側面があります。組織への報告やマネジメント構造は、実践が十分な支持と成熟度を獲得し、それらに影響を与えるまで、アーキテクト自身の判断で決定できない場合があります。役割、メンタリング、エンゲージメント定義などに基づくリーダーシップといった実務の実施に関しては、単純な実践コミュニティに基づいて実施することも、本格的なセンター・オブ・エクセレンス（CoE）までに拡大することも可能です。 　ただし、こうしたシニア制度も経験年数ではなく、能力と価値成果における実証された卓越性のみに基づくべきであることに留意が必要です。例えば、あるアーキテクトが長年この肩書きを持っていた、あまり成熟していない組織で、その影響力で肩書きを求めてきた場合を考えてみましょう。彼らは長年の経験を持っているかもしれませんが、能力やスキルモデルの重要な側面で多くの期間で挑戦を受けていないかもしれません。 　したがって、これらの個人は能力こそが「シニア」アーキテクトと「ジュニア」アーキテクトを区別する唯一の境界であることを理解することが不可欠です。開発者として何年働いても、ビジネステクノロジー戦略のスキルがない人もいます。また、少なくともアーキテクト職内でのメンタリングや役割配分にも影響します。必要に応じて、経験に基づく認定であるIasa CITA-P/D(注1)に合格することで、これらの役割をふるいにかけることができます。 ↑↑↑↑↑↑↑↑↑↑　以上　BTABoK　原文（翻訳）　↑↑↑↑↑↑↑↑↑↑   　 IASAにおける認定資格については、IASAGlobalに直接申し込むことも可能ですが、アジアパシフィックの研修体制の一環として日本でも受講できるようにしていくことを検討中です。詳細が決まりましたら、ご案内いたします。 　次に、BTABoKはコミュニティが遭遇するであろう課題と対応策について述べています。 ↓↓↓↓↓↓↓↓↓↓　以下　BTABoK原文（翻訳）↓↓↓↓↓↓↓↓↓↓　 専門分野とコミュニティ間の対立 　専門化活動や役割は、異なる専門分野間でしばしば衝突が生じるため、エンゲージメントモデルの早期段階で対処する必要があります。医学の専門分野を考えると、その違いや内部抗争がなぜ医療機関にとって危険なのかを理解するのに役立つかもしれません。外科医と一般開業医、ERで働く医師はしばしば世界観が大きく異なりますが、どちらも医師と見なされています。この区別は、ビジネスアーキテクトとソリューションまたはソフトウェアアーキテクトが効果的に協働できるアーキテクチャ実務体制を設計する上で役立つでしょう。 質問1：専門家の必要性は？ 小規模な組織では、ソリューションアーキテクトやエンタープライズアーキテクトが、一般医に相当する役割を担うことが多くなります。彼らはビジネス、情報、インフラ、ソフトウェア、ソリューションアーキテクチャについて十分な知識を持ち、平均的な企業の製品やプロジェクトを成功に導くことが出来ます。 大規模なチームや高度に複雑な領域では、専門性が存在し、その数も多くなる傾向があります。ビジネスモデル、製品タイプ、業界へのデジタル浸透度などは、専門家が必要かどうかを判断する上でしばしば役に立ちます。例えば、ソフトウェア製品会社と大手銀行では、必要なビジネスアーキテクトの人数が大きく異なるでしょう。アーキテクチャチームキャンバスを活用し、現在のエンゲージメントモデルに専門家かジェネラリストが必要かを判断し、それに応じて採用・育成・指導を行ってください。 質問2：専門家をアサインする方法は？ アーキテクトのアサインは、あらゆる場所にすべてのアーキテクトを配置することは不可能であるため、特に難しい問題です。アサインに関する記述ではアーキテクトのアサインについて詳細なガイダンスとツールを提供していますが、専門家には特別な配慮が必要です。インフラストラクチャアーキテクトが在籍しているのに、データセンターの再構築にソフトウェアアーキテクトを充てるのは非効率的です。以下の内容を参考に、専門分野に基づいてアーキテクトの役割を定義し、アサインを行ってください。 １　一般的に、ソリューションアーキテクトは専門分野を横断する共通スキルに焦点を当てます。彼らは通常のプロジェクトにおける主要な担当者とされ、製品/プロジェクトの健全性のために必要に応じて専門家から支援を受ける自由を持つべきです。ビジネスアーキテクトと連携し、バリューストリームの提供を確実に行います。 2　大規模で複雑なドメイン特化型プログラムは、当該分野の非常に経験豊富なスペシャリストが主導すべきです。この際考慮すべき軸は3つあります。 1つ目は専門性（個人の能力と経験の主な焦点）、2つ目はドメイン特化（医学で言うサブスペシャリゼーション）です。例えば、小売ドメインに特化したソフトウェアアーキテクトであり、モバイルおよびウェブベースのソフトウェアに深いスキルを持つアーキテクトが該当します。配置において考慮すべき3つ目の軸は、ビジネスと個人への価値であります。多くのアーキテクトが特定のプロジェクトに情熱を注ぐ、この動機付けが実践にさらなる品質と利益をもたらします。 3　専門分野における深い知識を理由に、アーキテクトではない人材をアーキテクチャ業務のリーダーに任命することには注意が必要です。アーキテクトは、5つの能力の柱に基づいていなければならず、そうでない場合、その業務にはアーキテクトによる直接的な支援が必要となります。 ↑↑↑↑↑↑↑↑↑↑　以上　BTABoK　原文（翻訳）　↑↑↑↑↑↑↑↑↑↑   上記にある５つの能力とは、以下のようなことになります。 1抽象化思考力: 抽象的な視点で問題を捉え、全体の構造を理解することが重要です。 2仮説を立てて自力で絵が描ける能力: 問題解決のための仮説を立て、具体的な解決策を自力で考えることが求められます。 3俯瞰し・ゼロベースで考える能力: アーキテクトは新しい世界をゼロベースで構想できる力が必要です。新しいものを生み出すために、自分を固定観念から解放することが求められます。   4変革期に必要な新しい思考回路をインストールする能力: ニューノーマルの時代には、これまでの勝ち　パターンが通用しないため、新しい思考回路を身につけることが重要です。 5これらの条件を満たすアーキテクト人材は、ビジネスの川上において特に必要とされ、その力は抽象化　思考力として発揮されます。 アーキテクト人材には、ゼロベースで抽象度の高い全体構造を構想する能力、 新しい問題を解決するために、既存の枠組みを超えて考えることが求められます。専門知識の深さゆえに非アーキテクトをアーキテクチャ活動のリーダーに任命するのは慎重であるべきです。 　　 　最後に、多様な人材のコミュニティを円滑に運営していくためのアーキテクトのソフトスキルについて述べています。 ↓↓↓↓↓↓↓↓↓↓　以下　BTABoK原文（翻訳）↓↓↓↓↓↓↓↓↓↓　 拡張チーム：メンタリングとリーダーシップ 　アーキテクトコミュニティの質は、その奉仕者／リーダーとしての能力に比例します。しばしばソフトスキルと呼ばれるこれらの能力は、習得が最も困難な場合があります。メンタリングとリーダーシップは実践的なスキルであり、アーキテクトのキャリア初期段階で指導・評価されるべきです。新規アーキテクトは、適切なメンタリングのもと、エンジニアリング、運用、ビジネスなど他分野の専門家から転身するケースが多いのです。 　アーキテクトコミュニティは、リーダーシップとメンタリングプログラムを成熟させ、拡張チーム（Extended Team）について深く理解する必要があります。拡張チーム（ET）の考え方はこの分野に関する直接的な指針を提供しています。 ↑↑↑↑↑↑↑↑↑↑　以上　BTABoK　原文（翻訳）　↑↑↑↑↑↑↑↑↑↑   　 冒頭のBTABoKの記述にあるように、 「BTABoKでは「コミュニティ」という用語を、組織の内部および外部の拡張チーム（ET）メンバーのグループを指し、最良のビジネスおよび技術戦略を実現するために協力しなければならないことを指しています。」 というコミュニティに関する捉え方に鑑みると、IASA日本支部が外部の拡張チームの位置づけと言えるかと思います。 　IASA日本支部での活動は必ずや皆様のお役に立てると考えております。IASA日本支部のコミュニティ活動については、毎月発行のメールマガジンやホームページでお知らせしております。多くの方のご参加をお待ちしております。

要旨（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/権限）を運用設計として組み込むことが不可欠です。注 2 本コラムでは、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）として説明されます。注 1 また、エンゲージメントモデルは、中心にアーキテクチャロールを置き、その周囲に People / Value / Operating / Outcomes の4サブモデルを配置して、概念形成から価値実現までをライフサイクルとして扱います。注 2 ３．ITアーキテクチャ策定における生成AI（LLM）の有効領域 BTABoKの活動を『価値』『人』『運用』『成果』の観点で捉えると、LLMは特に次のような領域で効果を発揮します。 表1　BTABoK観点別：LLM活用タスク（例） BTABoK観点 LLMに任せる作業（例） アーキテクトが担う判断・検証 Value（価値） 価値仮説の言語化、ビジネスケースの要約、代替案の比較観点生成 投資対効果/リスク/制約の妥当性確認、意思決定責任 People（人） ステークホルダー論点整理、コミュニケーション計画草案、役割定義案 利害調整、責任境界（RACI）の確定 Operating（運用） 要求/ASR抽出、トレーサビリティ表（RTM）草案、ADRドラフト、レビュー観点提示 要件の真正性、合意形成、設計トレードオフ最終判断 Outcomes（成果） KPI候補抽出、測定設計案、運用データの要約/傾向分析 指標の有効性、組織目的との整合、改善施策の優先度 たとえば、Traceability（VM-T）は、ビジネスゴールからアウトカム、要求、意思決定へ価値を紐付けて追跡する方法として定義されています。注 3 またRequirements（OM-R）では、要求をソースから最終アウトカムまで追跡し、RTMにより『満たす/満たさない』も含めて文書化することが求められます。注 4 ４．Agentic AI：知覚→推論→行動→学習サイクルと外部ツール連携 Agentic AIは、知覚（Perceive）→推論（Reason）→行動（Act）→学習（Learn）の循環を持ち、LLMを中核に外部ツール（検索、API、実行基盤など）と連携して、複数ステップのタスクを自律的に実行できる点が特徴です。一方、企業利用では『検証（validity）』—出力が要件・制約・規制・運用現実に照らして正しいこと—を担保する仕組みが成功要因となります。注 8 ５．BTABoK × Agentic AI対応マップ BTABoKの4フェーズとAgentic AIの4サイクルを対応付けることで、各局面で『何を観測し、何を推論し、何を実行し、何を学習として残すか』を議論しやすくなります。注 1 表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・既存仕様から要求候補を抽出し、要求分類（機能/非機能/制約/規制）や論点の抜け漏れチェックリストを生成できます。一方で、要求の真正性（誰が言ったか、合意されたか）と優先順位づけ・採否判断は、最終的に人間側が責任を持つ必要があります。注 4 （2）代替アーキテクチャ案生成とトレードオフ分析 BTABoKでは、最初に提示された解が必ずしも最適とは限らない前提で、代替案比較と意思決定支援を重視します。LLMは、同一の要求集合に対して複数の構造案を提示し、品質特性（性能、可用性、セキュリティ、運用性など）の観点で差分を説明する用途に適します。ただし、品質特性のトレードオフは組織の優先度と制約に依存するため、結論はアーキテクトが根拠（測定計画・運用条件・規制等）とともに提示することが必要です。 （3）設計成果物（ADR/レビュー資料）自動整備と検証 設計の価値は図そのものではなく、なぜその判断に至ったか（理由・根拠・前提・代替案）にあります。LLMは、レビュー観点の体系化、アーキテクチャ決定の記録であるADR（Architecture Decision Record）への落とし込み、差分要約などの“文書化”に強みがあります。さらにAgentic AIとして、変更検知→影響範囲推論→関連ドキュメント更新→テスト/静的解析結果の取り込み、といった整合性維持を支援できます。注 5 （4）運用データを用いた継続的改善（Measurement/Learn） Maximise（Digital Operations）の局面では、運用監視データ、インシデント記録、問い合わせ、性能指標などが『知覚』の入力となります。Agentic AIは、異常兆候の要約、一次切り分けの支援、既知手順の提案、必要に応じたチケット起票などを連鎖的に実行できます。ただし、マルチステップのタスクでは誤りが複合化しうるため、重要操作の前段に検証と人間承認を置き、段階的に自動化範囲を拡張するのが実務的です。注 7 注 8 ７．ガバナンス設計（責任境界・検証・監査可能性） Agentic AIは『行動（Act）』を伴うため、単なる文章生成よりもガバナンスの要求水準が上がります。そのため導入時には、(a)誰が何に責任を持つか（RACI）、(b)どの入力を根拠とするか（データ境界）、(c)どの検証を通過したら実行可能か（validity gate）、(d)監査可能なログ（入力・出力・差分・承認）をどこに残すか、をアーキテクチャとして明示する必要があります。注 6 注 8 ８．おわりに 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

最近のシステム開発では、モデリング等の論理設計を省いていきなり実装とテストを繰り返しながらゴールに辿り着くという実装主義が、Z世代にとっては主流になりつつあるようだ。確固たる方法論に基づいた設計ありきの構築をしてきた設計主義のベテランアーキテクトは、この理屈にこだわらない開発手法に取って代わられることに、ある種の喪失感を感じざるを得ない。 この事はテクノロジーの進化によって詳細なロジックをカプセル化する事で、生産性と品質を追求した果てにたどり着くものである。これにより、エンジニアは自ら産み出したプロダクトによって職を失いかねないというジレンマに陥ることになる。とは言え、ことさら古いやり方の良さを吹聴し、技術の進化に対する危険性のみを主張する輩は見苦しい老害と言えよう。絶えず新しいテクノロジーを用いて生産性を追求することはエンジニアの取るべき道筋である。ではシニアアーキテクトは黙ってリタイヤすれば良いのだろうか。 この疑問が生じる背景には、良い道具さえあれば問題が解決するというツール至上主義がある。これが行き過ぎた場合には、ゆるぎないセオリーをも踏み外すことさえある。結果的に試行錯誤を繰り返すあまり、せっかくの自動化もかえって多くの時間とコストを費やしかねない。その典型的な例がAIである。AIは整理整頓が出来ていないビッグデータから高速に整理した結果を出力するパワーを秘めている。過去にセオリーを学んでいない人もそれなりの出力が期待できるので、ロジックを追求する必要は無駄だと考える。しかし、どんな優れたAIもGarbage in Garbage out であり、予期しない結果が出た場合には誤りの箇所を発見することに苦労することになる。 ベテランはこのようなアンチパターンを唯々見過ごすのではなく、嫌がられることを恐れずに優しくアドバイスを与える必要がある。また、一方のZ世代もベテランのアドバイスを鬱陶しいと拒絶するのではなく、時には耳を傾けることが必要である。企業内のIT従事者を30~60歳の従業員と仮定すると、過去30年間でIT従事者はほぼ全てが入れ替わったことになる。この間、IT（情報技術）は劇的な変化を遂げたものの、IS（情報システム）の本質的なロジックは普遍的なものが多い。にも関わらずZ世代の担当者にはISの普遍的ロジックを学ぶ機会が与えられてこなかった。 歴史の浅いIT業界の従事者は本質が変わっていないにも関わらず、道具が変わることで全てを一からやり直すというムダな時間を費やしてきた。これまでベテランが有するセオリーを伝承してこなかったソフトウェア開発も、建築、機械、電気といったハードウェアと同様に、設計図（モデル図）で次世代に継承することが求められる。進化し続けるITを用いたシステム開発は、全てをゼロベースからやり直すのではなく、モデルに立ち戻ることで効率的なリスタートが可能になる。また、根本的にモデルを変えるDXにおいては、なおさら現在のモデルとの対比を明らかにする必要がある。今日、行き過ぎた実装主義に警鐘をならし、論理設計を重視することは、若手、ベテランを問わず考えなければならない大きな課題である。 　Iasa日本支部ではITアーキテクチャに関する情報交換や勉強会の場を設けております。みなさんと一緒にアーキテクチャに関する学びを深めていければと思いますので、是非ともIasa日本支部の活動へのご参加、ご協力をよろしくお願いします。

bijinesuakitekuchabenkyokai-bizboksamaribanworindokushiyou-1 [ビジネスアーキテクチャ勉強会 第２回] 「BIZBOKサマリー版を学習しよう」 * *

dai1kai-archimatenokisowomanabou-zen12kai-1 「ArchiMateの基礎を学ぼう (全12回)」第2回 * *

iasanipponshibu-archimatebenkyokai-edgyttenan-zen6kai [Iasa日本支部 ArchiMate勉強会]「上流って何？」(全6回)」 * *