グローバルに通用するIT アーキテクトの
知識とスキル体系の普及へ

コラム一覧はこちら

新着コラム

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

2026年3月14日

平井均

要旨（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, エンゲージメントモデル, ガバナンス, 検証...

実装主義と設計主義　　～シニアアーキテクトからの警鐘～

2026年2月14日

中山嘉之

最近のシステム開発では、モデリング等の論理設計を省いていきなり実装とテストを繰り返しながらゴールに辿り着くという実装主義が、Z世代にとっては主流になりつつあるようだ。確固たる方法論に基づいた設計ありきの構築をしてきた設計主義のベテランアーキテクトは、この理屈にこだわらない開発手法に取って代わられることに、ある種の喪失感を感じざるを得ない。この事はテクノロジーの進化によって詳細なロジックをカプセル化する事で、生産性と品質を追求した果てにたどり着くものである。これにより、エンジニアは自ら産み出したプロダクトによって職を失いかねないというジレンマに陥ることになる。とは言え、ことさら古いやり方の良さを吹聴し、技術の進化に対する危険性のみを主張する輩は見苦しい老害と言えよう。絶えず新しいテクノロジーを用いて生産性を追求することはエンジニアの取るべき道筋である。ではシニアアーキテクトは黙ってリタイヤすれば良いのだろうか。この疑問が生じる背景には、良い道具さえあれば問題が解決するというツール至上主義がある。これが行き過ぎた場合には、ゆるぎないセオリーをも踏み外すことさえある。結果的に...

BTABoK Decisions ～ AI時代のアーキテクチャ意思決定～

2026年1月15日

松井淳

新年明けましておめでとうございます。2026年、私たちのエンジニアリング環境は、生成AIの急速な進化によって劇的な変化の中にあります。あらゆる仕事の自動化が進み「人でしかやれないこと」との境界線が問われる今、アーキテクトにとって最も重要なテーマは、技術の選択を超えた「意思決定」の本質に立ち返ることではないでしょうか。本稿ではアーキテクチャ意思決定をテーマに、グローバルな知見であるBTABOK（Business Technology Architecture Body of Knowledge）を紐解きながら、これからのアーキテクトが担うべき役割を考察します。参考 IASA Global, BTABoK – Decisions https://iasa-global.github.io/btabok/decisions.html ※本コラムはBTABoKの内容を要約・解釈したものであり、厳密な定義や詳細は原典を参照してください。・今なぜ意思決定が主要テーマとなるのか昨今の生成AIの熱狂は、ソフトウェア開発の風景を一変させました。コード生成からデバッグ、ドキュメント作...

BTABoK Technical Debt ～アーキテクトは技術的負債とどう向き合うべきか～

2025年12月12日

川森脩平

はじめに今回のコラムでは、BTABoKにおけるバリューモデルの一つである Technical Debt について取り上げます。 Technical Debt（技術的負債）という言葉は日本企業でも広く聞かれるようになりました。しかし、現場での使われ方を見ていると「未完了の作業」「気になるコード」「バグ」「古いシステム」など実に幅広いものがすべて技術的負債と呼ばれています。本来の意味が曖昧なまま使われることで、かえって問題が見えづらくなる場面も多いのではないでしょうか。本稿では、BTABoKの整理を土台にアーキテクトとして技術的負債をどう捉え、どう扱うべきかを考えてみます。技術的負債とはもとはWard Cunninghamが示した比喩で、短期的に価値提供を優先するために、あえて最適でない設計を選ぶことを負債に例えたのが始まりです。本質は次の一点にあります。短期的には便利だが、将来の変更を高価に、あるいはほぼ不可能にする構造的な選択であること。コードをリファクタリングしてすぐに返済する限り、負債を一時的に抱えること自体は問題ありませんし、有益でさえあります。ところが実務の...

(個人・法人会員限定) アニュアル・カンファレンス 2025 講演資料

2025年11月29日