アーキテクチャ設計 ── AIを設計相談に使う作法── 助言の使い方、トレードオフ、人が負う責任

01設計判断とは何か ── 「後で変えにくいこと」を決める

アーキテクチャ設計という言葉は大げさに聞こえますが、中身は単純です。後から変えるのが難しいことを、先に決める。これに尽きます。Martin Fowler は、アーキテクチャを「その分野に詳しい人たちが重要だと考えること、そして変更が難しいこと」と説明しています。変数名やボタンの色は、後でいくらでも直せます。しかし、データベースの種類、システムを分ける境界線、外部サービスとの依存関係は、一度決めて動き出すと、覆すのに大きなコストがかかります。

だから設計判断には、通常のコード修正とは違う重さがあります。判断を分けて考えると、扱いが見えてきます。

• 可逆な判断 ── 間違えてもすぐ戻せる。関数の分け方、ライブラリの選定の一部。ここは速く決めて、走りながら直す
• 準可逆な判断 ── 戻せるが痛い。API の形、データの持ち方。決める前に一度立ち止まる価値がある
• 非可逆に近い判断 ── 事実上戻れない。基盤となるデータベース、システム間の境界、外部依存の中核。ここは時間をかけて決める

この重みの違いを意識せず、すべてを同じ速さで決めてしまうと、後で響きます。可逆な判断に悩みすぎて時間を溶かし、非可逆な判断を勢いで決めてしまう ── これが設計でいちばんよくある失敗です。

02AIの助言の使い方 ── 決めさせるのではなく、視野を広げる

生成 AI には、設計相談の相手として得意な面がいくつかあります。一方で、任せてはいけない領域もはっきりしています。この両方を分けて使うのが作法です。

AI の助言には、特有の癖があります。まず、流暢さと正しさは別物です。整った文章で断言されると正しく見えますが、根拠が薄いことは珍しくありません。次に、AI は質問に引きずられます。「マイクロサービスにすべきか」と尋ねれば、それを推す方向の答えが返りやすい。中立に聞くには、「この要件には単一構成と分割構成のどちらが妥当か、両方の観点で」と、選択肢を対等に並べて尋ねます。

そして最大の注意点は、AI があなたの制約を全部は知らないことです。予算、チームの人数、既存システムとの兼ね合い、社内の承認プロセス、規制要件 ── どれも設計を大きく左右しますが、明示しない限り AI の答えには反映されません。教科書どおり正しくても、自社では回らない案が平気で出てきます。

03ADRで残す ── なぜそう決めたかを言葉にする

設計判断は、決めた瞬間より、半年後のほうが問われます。「なぜこの構成にしたのか」を誰も思い出せず、触るのが怖くて放置される ── よくある光景です。これを防ぐ軽い仕組みが ADR（＝アーキテクチャ決定記録、Architecture Decision Record）です。Michael Nygard が 2011 年に提唱した、1 件の判断を 1 枚のごく短い文書に残す方式です。

ADR は重厚な設計書ではありません。1 判断あたり、数分で書ける分量が目安です。書くのは、ふつう次の項目だけです。

• タイトルと状態 ── 「採用」「非推奨」「置換済み」など。後から状態だけ更新できる
• 背景（Context） ── どんな状況で、何を決める必要があったか。制約もここに書く
• 決定（Decision） ── 何を選んだか。一文で言い切る
• 結果（Consequences） ── その選択で何が良くなり、何を引き受けることになったか。負の面も正直に書く

AI との相談は、ADR と相性が良い。相談の過程で出た選択肢とトレードオフが、そのまま「背景」と「結果」の素材になるからです。ただし、AI が出した文章をそのまま貼らない。自分の言葉で、自分たちの制約に照らして書き直す。この書き直しそのものが、判断を自分のものにする工程になります。

04トレードオフの見極め ── 「良い設計」は状況で変わる

設計に唯一の正解はありません。あるのは、状況ごとの釣り合いの取り方だけです。同じ要件でも、3 人のチームと 30 人のチームでは正しい構成が変わります。AI に助言を求めるときも、この釣り合いを自分で握っていないと、一般論に流されます。

典型的な対立軸を、対比で押さえておきます。

AI に尋ねると、しばしば拡張性の高い、立派な構成を勧めてきます。教科書のうえでは正しい。しかし、来るかどうか分からない将来のために今の単純さを捨てるのは、たいてい割に合いません。「その柔軟性は、いつ、どのくらいの確率で必要になるか」を自分に問い、確率が低ければ単純な案を選ぶ ── この判断は、文脈を知る人にしかできません。

ソフトウェアの品質特性を整理した国際規格 ISO/IEC 25010 は、保守性・性能効率性・信頼性・セキュリティなど複数の品質を並べています。大事なのは、これらを同時に最大化できない点です。どれを立て、どれを妥協するか。その優先順位づけこそが設計判断の本体であり、AI に丸投げできない部分です。

05検証 ── 助言を鵜呑みにしない確かめ方

AI の設計助言は、そのまま採用せず、いくつかの角度から確かめます。動いた設計が正しい設計とは限りません。以下は、決める前の最低限のチェックです。

• 根拠を尋ね返す ── 「なぜその案が良いのか、具体的な理由を 3 つ」と聞く。理由が薄ければ、その助言は信頼度が低い
• 反対案を出させる ── 「この案に反対する立場なら、どう批判するか」を同じ AI に尋ねる。一貫して同じ答えしか出ないなら、視野が狭い可能性
• 最小構成で試す ── 重要な判断は、小さな試作（＝プロトタイプ）で確かめてから本採用する。紙の上の正しさと、動かしたときの手触りは違う
• 制約を追加して聞き直す ── 予算・人数・既存システムを明示して尋ね直すと、最初の答えが崩れることがある。崩れる助言は、その程度のものだった

特に、複数の AI や複数の情報源に当たると、助言の偏りが見えてきます。1 つのモデルが強く勧める案でも、別の観点を入れると評価が変わる。設計の検証は、コードのテストのように自動化しにくいぶん、人の側で「疑う手順」を型として持っておく必要があります。

06人の責任 ── AIは助言し、人が決めて負う

ここが本回の核心です。AI がどれだけ流暢に助言しても、その設計を選んだ責任は、選んだ人にあります。「AI がそう言ったから」は、後から通用しません。障害が起きたとき、監査で問われたとき、説明を求められるのは人の側です。

この責任の所在を曖昧にしないために、いくつかの線を引いておきます。

• 最終判断は明示的に人が下す ── AI の出力を承認する工程を、形だけでも人が通す。自動で流さない
• 判断の記録に人の名前を残す ── ADR に誰が決めたかを書く。責任者が不在の判断を作らない
• 説明できない設計は採用しない ── 自分の言葉で理由を語れない案は、たとえ AI が勧めても保留する。理解していないものは守れない

製薬・医療の文脈では、この原則がさらに重くなります。患者データの扱い、システムの信頼性、変更管理 ── どれも「人が判断し、その判断を説明できる」ことが前提です。AI を設計に使うこと自体は問題ありませんが、責任の主体まで AI に移すことはできません。ツールは助言者であって、意思決定者ではない。この一線を、便利さの中で見失わない ── それが作法の芯です。

07運用 ── 設計は一度で終わらない

設計は、リリースした瞬間に完成するものではありません。動かし続けるなかで、想定と現実のずれが見えてきます。アーキテクチャは育てるものと捉えると、AI との付き合い方も変わります。

運用の局面で AI が役立つのは、次のような場面です。

• ずれの発見 ── ログや障害の傾向を説明し、「設計のどこに無理が出ているか」を一緒に探る
• 変更の影響範囲の洗い出し ── 「ここを変えると、どこに波及するか」を列挙させ、見落としを減らす
• 過去の ADR の棚卸し ── 状況が変わり、当時の判断がもう合わないものを、AI に候補として挙げさせる

ここでも原則は同じです。AI は気づきの補助線を引くのが得意ですが、変えるかどうかを決めるのは人です。当時の判断を今の基準で断罪しない ── ADR の「背景」を読み返し、その時点では妥当だったと理解したうえで、更新するかどうかを判断する。設計の履歴を尊重する態度が、長く保守できるシステムを支えます。

08他章との接続

本回のアーキテクチャ設計は、シリーズの他の回と地続きです。読み合わせると、設計から実装、そして協働までの流れが見えてきます。

• 要件を言葉にする力 ── 設計の前段には、何を作るかの言語化があります。曖昧な要件のまま AI に設計を頼むと、曖昧な答えしか返りません
• 検証と品質保証 ── 設計判断の正しさは、テストと運用で確かめられます。設計と検証は往復します
• 次回のペアプロ作法 ── 設計を決めたあと、実装の局面で AI とどう協働するか。判断の重さが違うぶん、付き合い方も変わります

アーキテクチャ設計は、AI 活用のなかでも、もっとも人の判断が問われる領域です。実装は AI が肩代わりできる部分が増えてきましたが、何を作り、何を捨て、なぜそう決めたかは、人が握り続ける。この主導権を手放さないことが、AI 時代の設計者に残された仕事です。

AI に設計を相談できる時代になって、便利さは確実に増えました。選択肢を広げ、トレードオフを並べ、前提を疑う相手として、AI は優秀です。しかし、その優秀さは助言者としての優秀さであって、意思決定者としてのものではありません。流暢な断言に流されず、自分の制約に照らして選び、選んだ理由を ADR に残し、その責任を人が負う ── この一連の型は、モデルがどれほど賢くなっても変わりません。

むしろ AI が賢くなるほど、助言はもっともらしくなり、鵜呑みにする誘惑は強まります。だからこそ、決めるのは人、負うのも人、という一線を、作法として先に引いておく。AI を設計相談に使うとは、判断を渡すことではなく、判断の質を上げるために使うことです。次回は、設計を決めたあとの実装の局面 ── 人と AI が並んでコードを書く「ペアプロ作法」に進みます。