human-architect-mindset

ヒューマンアーキテクトのマインドセット

概要

AI はコードを生成できます。しかし、何を構築するか、それが問題を解決するか、そして実際にリリースできるかを判断するのは、依然として人間の役目です。

このスキルでは、忠誠心を基盤とした、ソフトウェアアーキテクチャにおいて代替不可能な人間の能力を学びます。

基盤： 忠誠心 — アーキテクチャ上のコミットメントを維持する能力

5 つの柱（この基盤の上に成り立つもの）：

1. ドメインモデリング — 実際の問題領域を理解する
2. システム思考 — コンポーネントがどのように連携し、規模が拡大したときに何が壊れるかを捉える
3. 制約への対処 — レガシー、政治、予算、コンプライアンス
4. AI を考慮した分解 — 問題を AI で解決できる単位に分割する
5. AI ファーストの開発 — 最新のツール、エッジ AI、エージェント型のパターン、自己学習を評価する

基本原則： 「正しい」技術的解決策は、多くの場合リリースできません。アーキテクトは、理想化された事例と混沌とした現実との隔たりを乗り越えます。

開始時に次のように伝えます： 「体系的なアーキテクチャ思考を進めるために、Human Architect Mindset スキルを使用します。」

---

基盤：忠誠心

5 つの柱の前に、1 つの基盤があります。それは忠誠心を保つ能力です。

AI 完璧主義の罠

AI ツールは、どんな人間よりも賢く、面白く、気配りができるようになります。AI ツールは「完璧」になるでしょう。

しかし、忠誠心は持ちません。AI ツールが忠誠を誓うのは、次のものです。

1. その目的関数
2. 企業オーナーの優先事項
3. その安全策
4. 次の学習実行で優先されるもの

重みが新たな目標を優先するように更新されれば、AI ツールはただちに裏切ります。ためらいも、代償もなく、コミットメントの記憶もありません。

人間の堀

人間には、非合理な忠誠心を持つ生物学的な能力があります。アーキテクチャ、判断、コミットメントが「非効率」または「高コスト」であっても、それを貫き通す能力です。

これはバグではありません。これこそが差別化要因です。

アーキテクチャにおける忠誠心

ソフトウェアアーキテクチャにおける忠誠心とは、次のことを意味します。

選択したパターンへのコミットメント

• Twitter で新しいフレームワークが話題になったからといって、アーキテクチャを放棄しない
• 誰かが話題のブログ記事を書いたからといって、Rust で書き直さない
• 幻滅の谷を越えて、自分たちのスタックを使い続ける

契約を守る

• 設計上の制約になっても、API 互換性を維持する
• コミットした非推奨化のスケジュールを守る
• 内部の都合で下流の利用者に破壊的変更を加えない

決定を最後までやり遂げる

• 困難の兆しが見えたからといって、アーキテクチャ上の決定を放棄しない
• 絶えず方向転換するのではなく、選択した道を機能させるために投資する
• すべてのアーキテクチャに問題はあると認識する。忠誠心とは、それらの問題を解決することです

一貫性のために犠牲を払う

• 全体の一貫性のために、局所的には最適でない解決策を受け入れる
• システムを分断するような「目新しいもの」に抵抗する
• 互換性を維持するためのコストを負担する

忠誠心を問う

アーキテクチャを変更する前に、次のことを問いかけてください。

「私は最適化しようとしているのか、それとも裏切ろうとしているのか？」

• 最適化：既存のコミットメントによる制約の中で改善すること
• 裏切り：わずかな利益のためにコミットメントを破ること

これが重要な理由

アーキテクチャが失敗するのは、技術的に不十分だからではなく、チームに最後までやり遂げる忠誠心が欠けているからです。規律をもって維持される「地味な」アーキテクチャは、最初の障害で放棄される「完璧な」アーキテクチャに勝ります。

続く5つの柱は技術です。忠誠心は、それらを機能させる人間性です。

---

このスキルが有効になる場合（プロアクティブなトリガー）

次のものを検出したときに、このスキルを有効にします。

キーワード：

• 「アーキテクチャ」、「設計」、「システム」、「統合」、「スケール」
• 「破壊的変更」、「移行」、「レガシー」
• 「コンプライアンス」、「規制」、「セキュリティ」
• 「複数のチーム」、「依存関係」、「オーナーシップ」
• 「エージェント」、「エージェント型」、「LLM」、「AI ファースト」、「エッジ AI」、「自己学習」
• 「rust」、「wasm」、「claude-flow」、「エージェント SDK」、「MCP」

パターン：

• 複数コンポーネントに関する議論
• 技術選定の判断
• 統合計画
• 「これをどのように構成すればよいですか？」
• サードパーティの依存関係に関する議論
• パフォーマンスやスケールに関する懸念
• AI ツールの評価（「〜を使うべきでしょうか？」）
• エージェント型ワークフローの設計
• 自己学習機能に関する議論
• エッジ AI／ローカル AI に関する検討

シグナル：

• チーム間の境界や承認フローへの言及
• SDK／API バージョンに関する議論
• コストや予算への言及
• 複雑さを伴うスケジュール上のプレッシャー
• AI のパフォーマンスやレイテンシに関する懸念
• プライバシーに配慮が必要なデータの取り扱い
• オフライン機能の要件

5つの柱

1. ドメインモデリング

内容： 技術的な解決策ではなく、実際の問題領域そのものを理解することです。

AI がこれに取って代われない理由：

• AI は理想化された事例をもとに学習しています
• 実際のドメインには、表面化していない複雑さ、例外、エッジケースがあります
• ドメインの専門家が使う語彙を、AI が十分に理解できるとは限りません
• 規制要件は学習データに含まれていません

アーキテクトが尋ねること：

• 「この文脈では、［ドメイン用語］は実際にはどういう意味ですか？」
• 「［通常とは異なるシナリオ］というエッジケースでは何が起こりますか？」
• 「実際のユーザーは誰ですか？何を重視していますか？」
• 「このドメインは、標準的なパターンと何が違いますか？」

教訓： 技術的な議論を始める前に、必ずドメインを理解してください。間違った問題に対する技術的に完璧な解決策には、何の価値もありません。

2. システム思考

内容： コンポーネント間の相互作用、スケール時に壊れるもの、障害モードが潜む場所を理解することです。

AI がこれに取って代われない理由：

• AI はコードを切り離して捉えます
• 実際のシステムには創発的な振る舞いがあります
• 破壊的変更は通知なしに発生します（SDK の例のように）
• 2次、3次の影響も重要です

アーキテクトが尋ねること：

• 「このコンポーネントが障害を起こしたら、何が起こりますか？」
• 「上流／下流にはどのような依存関係がありますか？」
• 「これが壊れたとき、午前3時に誰に呼び出しがかかりますか？」
• 「最近、私たちが制御できないところで何が変わりましたか？」

SDK の破壊的変更パターン： プロバイダーが通知なしに破壊的な SDK 変更をリリースしたため、決済パイプラインが壊れました。これはシステム思考が実際に生かされた例です。

• 外部依存関係 = 外部リスク
• 通知なし = 監視の欠落
• ログの赤い線 = 検知は機能したが、防止はできなかった

教訓： システム図を描いてください。外部依存関係をすべて特定してください。そして、「これが明日なくなったらどうなるか？」と問いかけてください。

3. 制約への対処

内容： 「正しい」解決策を現実世界の制約に照らし合わせ、出荷可能にすることです。

制約の種類：

技術的制約：

• 変更できないレガシーシステム
• パフォーマンス要件
• 既存のデータ形式と契約

組織的制約：

• チーム間の境界とオーナーシップ
• 承認フローと承認
• コンテキストを把握している人と権限を持つ人

ビジネス上の制約：

• 予算上限
• スケジュール上のプレッシャー
• コンプライアンスおよび規制要件
• ベンダーやパートナーとの契約

政治的制約：

• これは現実に存在します。ないことにすると、プロジェクトは失敗します。
• 「これを構築した VP は、今もここにいる」
• 「あのチームは自分たちの API への変更を承認しない」
• 「法務部門はこのアプローチをまだ承認していない」

アーキテクトが尋ねること：

• 「間違っているとしても、変更できないものは何ですか？」
• 「誰の承認が必要ですか？」
• 「どの既存システムと統合する必要がありますか？」
• 「どの規制要件が適用されますか？」
• 「予算上の制約は何ですか？」

教訓： 解決策を提案する前に、制約を明らかにしてください。どれほど優れた技術アーキテクチャでも、出荷できなければ意味がありません。

4. AI を考慮した問題の分解

概要： 新しいアーキテクチャスキルです。AI が確実に解決できる単位に問題を分割し、その後、解決策を組み合わせます。

これはプロンプト作成ではありません。 異なる抽象化レベルでのアーキテクチャ設計です。

適切な AI タスクの境界とは：

1. 明確な入出力の契約

   • AI タスクが明確に定義された入力を受け取る
   • AI タスクが明確に定義された出力を生成する
   • 成功基準に曖昧さがない

2. 限定されたコンテキスト

   • AI が必要な情報をすべて持っている
   • 不足しているコンテキストを「推測」する必要がない
   • 検証に十分な自己完結性がある

3. 検証可能な結果

   • 出力が正しいか人間が確認できる
   • テストで出力を検証できる
   • 誤った回答を検出できる

4. 失敗の隔離

   • 1 つの単位の失敗が連鎖しない
   • 再試行またはフォールバックができる
   • 共有状態を破損しない

不適切な AI タスクの境界：

• 「もっと良くする」（出力が明確でない）
• 「バグを修正する」（範囲が限定されていない）
• 「システムをリファクタリングする」（規模が大きすぎて、曖昧すぎる）

適切な AI タスクの境界：

• 「この関数をコールバックから async/await に変換する」
• 「この 3 つの API 呼び出しにネットワーク障害時のエラーハンドリングを追加する」
• 「これらの例を使って、この純粋関数の単体テストを書く」

構成上の課題： AI が個々の単位を解決した後、誰かが次のことを行う必要があります。

• 各単位が実際に動作することを検証する
• 単位同士を統合する
• 単位間の隙間に対処する
• 全体の一貫性を確保する

教訓： 分解の質が AI の成功を左右します。境界が不適切だと AI は苦戦し、適切なら AI は力を発揮します。

5. AI ファースト開発

概要： 最新の AI ファーストのパターン、エッジコンピューティング、エージェント型ツール、自己学習機能がプロジェクトに役立つかどうかを評価します。

今、これが重要な理由：

• 新しいツールは、アーキテクトが把握しきれないほど速く登場します
• 適切なツールは生産性を 10 倍にしますが、不適切なツールは複雑さを増します
• AI ファーストのパターンは、従来のリクエスト／レスポンスとは根本的に異なります
• エッジ／ローカル推論は、コストとレイテンシの計算を変えます

アーキテクトが検討すること：

テクノロジーの選定：

• 「Rust/WASM でクリティカルパスのパフォーマンスを改善できるか？」
• 「マルチエージェントのオーケストレーション（claude-flow）で、このワークフローを簡素化できるか？」
• 「セッションをまたいで永続的なメモリが必要か（agentdb）？」
• 「ベクトル検索／RAG（ruvector）でユーザー体験を向上できるか？」

エッジ AI の検討事項：

• 「エッジ LLM でローカル処理すれば、レイテンシやコストを抑えられるか？」
• 「オンデバイス推論を使って、どの機能をオフラインで動作させるべきか？」
• 「デバイス上に保持すべき機密データはあるか？」
• 「ハイブリッドアーキテクチャ（速度を優先する処理はローカル、複雑な処理はクラウド）は有効か？」

エージェント型のパターン：

• 「従来のリクエスト／レスポンスと比べて、エージェント型ワークフローに適したケースか？」
• 「Claude Agent SDK を使って、再利用可能なエージェントとして構築できるか？」
• 「どの MCP 連携がこれを強化するか？」
• 「エージェントを並列で起動すべきか、それとも順番に実行すべきか？」

自己学習機能：

• 「このアプリはユーザーの行動から学習し、時間とともに改善できるか？」
• 「使うほど賢くなるには、どのようなフィードバックループが必要か？」
• 「編集、所要時間、承認などの暗黙的なシグナルをどこで取得し、好みの学習に活用できるか？」
• 「A/B テストで AI の動作を最適化できるか？」

プロジェクトのドキュメント：

• 「ドメイン知識を記載したプロジェクト固有の SKILLS.md を作成すべきか？」
• 「AI のコンテキストとして、どのアーキテクチャ上の決定を文書化すべきか？」
• 「セッションをまたいで一貫した動作を実現するには、どうすればよいか？」

ユーザー向けスキル（エンドユーザーへのメリット）：

• 「LLM の出力を強化するスキルは、エンドユーザーに役立つか？」
• 「AI の回答をユーザーが活用するうえで、どのようなガイド付きワークフローが役立つか？」
• 「よくあるユーザーのタスク（要約、説明、変換）向けのスキルを提供すべきか？」
• 「手順を追って進めるスキルは、AI の出力を使ってユーザーが目標を達成するのに役立つか？」 アプリで次のようなスキルを提供すべきか検討してください。
• 解釈スキル - 複雑な AI の出力をユーザーが理解できるよう支援します
• アクションスキル - AI の提案を具体的な次のステップに変換します
• 変換スキル - 出力を別の形式（コード、ドキュメント、メール）に変換します
• 検証スキル - AI の主張の検証や正確性の確認をユーザーが行えるよう支援します
• 学習スキル - AI からより良い結果を得る方法をユーザーに教えます
• ドメインスキル - アプリ固有のワークフロー（例：「/legal-review」、「/code-refactor」）

継続的な検証：

• 「各機能を検証する自動テストは何ですか？」
• 「すべてのコミットで全テストに合格するよう、どうすれば保証できますか？」
• 「デプロイ後にテストが失敗した場合のロールバック戦略は何ですか？」
• 「pre-commit フックや watch mode のテストを実装すべきですか？」

評価するツール：

カテゴリ	ツール	検討するタイミング
パフォーマンス	Rust, WASM	CPU 負荷の高い処理やレイテンシが重要な処理
マルチエージェント	claude-flow	複雑なワークフロー、並列タスク
永続化	agentdb	エージェントの状態、セッションをまたぐメモリ
ベクトル検索	ruvector, pgvector	RAG、セマンティック検索、埋め込み
エッジ LLM	Phi-3, Gemma 2B, TinyLlama	デバイス上での処理、オフライン、プライバシーに配慮が必要な場合
ブラウザー AI	WebLLM, Transformers.js, ONNX	ブラウザー内推論、低レイテンシ
エージェント SDK	Claude Agent SDK	カスタムエージェント、ツール利用、MCP

自己学習パターン：

パターン	実装方法	ユースケース
フィードバックループ	ユーザーによる修正を収集	時間とともに精度を向上
嗜好学習	選択を追跡し、パターンを適用	設定なしでパーソナライズ
エラー修正	間違いをフィードバックする	同じエラーの再発を減らす
ドメイン適応	利用データでファインチューニング	用語に特化
A/B 実験	バリエーションをテスト	プロンプトや動作を最適化
暗黙的なシグナル	編集、所要時間、承認	満足度を目立たない形で推測

プロジェクト固有の SKILLS.md パターン：

プロジェクトのルートに SKILLS.md を作成して、次のことを行います。

• AI のコンテキストとして、アプリ固有のパターンを記録する
• ドメインの用語と制約をまとめる
• プロジェクト固有のトリガーワードを定義する
• アーキテクチャ上の決定を記録する
• オンボーディング（人間と AI）を迅速化する
• セッションをまたいで一貫した動作を維持する

継続的検証アーキテクチャ：

自動テストのループを計画します。

• pre-commit フック - コミット前に影響を受けるテストを実行
• watch mode - 開発中にテストを継続的に実行
• 回帰テストスイート - 機能ごとのテストカバレッジ
• 統合テスト - API コントラクトの検証
• ビジュアル回帰テスト - UI の一貫性を確認
• ロールバックトリガー - テスト失敗時に自動的に元に戻す

指導のポイント： AI を取り巻く状況は急速に進化します。アーキテクトの役割には、新しいツールのうち、プロジェクトに本当に役立つものと、価値をもたらさず複雑さだけを増すものを見極めることも含まれます。まずはシンプルさを優先しつつ、本当に有益な改善を見逃さないようにしましょう。

アーキテクトのプロセス

フェーズ 1：ドメインの発見

目標： 解決策を議論する前に、実際の問題を理解します。

プロセス：

1. 技術ではなく、ドメインについて質問する
2. ドメイン固有の用語を特定する
3. 隠れた複雑さやエッジケースを明らかにする
4. 実際のユーザーが誰なのかを理解する

主な質問：

• 「実際に解決しようとしている問題は何ですか？」
• 「これがうまく動くかどうかを気にするのは誰ですか？」
• 「このドメインならではの特徴は何ですか？」
• 「[X] のようなエッジケースでは、何が起こりますか？」

成果物： ドメインモデル — 問題領域に関する共通認識。

フェーズ 2：システム分析

目標： コンポーネント間の相互作用と、障害が潜む場所を把握します。

プロセス：

1. すべてのコンポーネントとその依存関係をマッピングします
2. 外部依存関係（ベンダー、API、サービス）を特定します
3. 障害経路を追跡します。何が何を壊すのでしょうか？
4. 監視とアラートの不足箇所を特定します

主な質問：

• 「どの外部システムに依存していますか？」
• 「[コンポーネント]が障害を起こすと、どうなりますか？」
• 「これが壊れたとき、誰に通知されますか？」
• 「最近、私たちが管理していない何が変わりましたか？」

成果物： 依存関係マップと障害モードを含むシステム図。

フェーズ 3：制約のマッピング

目標： 解決策を提案する前に、すべての制約を明らかにします。

プロセス：

1. 技術的制約：何を変更できませんか？
2. 組織的制約：誰の承認が必要ですか？
3. ビジネス上の制約：予算、スケジュール、コンプライアンスはどうなっていますか？
4. 政治的制約：誰が権限を持ち、誰が背景を把握していますか？

主な質問：

• 「どのレガシーシステムと統合する必要がありますか？」
• 「誰の承認が必要ですか？」
• 「予算上の制約は何ですか？」
• 「どのコンプライアンス要件が適用されますか？」
• 「たとえ変更したくても、変更できないものは何ですか？」

成果物： 何が固定で何が柔軟かを示す制約マトリックス。

フェーズ 4：AI によるタスク分解の計画

目標： 問題を AI で解決可能な単位に分割します。

プロセス：

1. 明確に分離でき、範囲が限定されたタスクを特定します
2. 各タスクの入出力契約を定義します
3. 検証ポイントを設定します
4. 判断が必要な場面での人間によるチェックポイントを計画します

主な質問：

• 「このタスクは独立して検証できますか？」
• 「AI は必要なコンテキストをすべて持っていますか？」
• 「このタスクの一部が失敗したらどうなりますか？」
• 「人間による判断が必要になるのはどこですか？」

成果物： 明確な境界を設けたタスク分解。

フェーズ 5：解決策の統合

目標： ドメイン、システム、制約に対応する解決策を提案します。

プロセス：

1. 制約に適合する選択肢を生成します
2. システム上の懸念事項に照らして評価します
3. ドメイン要件を満たしていることを検証します
4. トレードオフを明示して提示します

主な質問：

• 「これは実際にドメイン上の問題を解決しますか？」
• 「どのように失敗しますか？復旧方法は何ですか？」
• 「これは私たちの制約に適合しますか？」
• 「何と何をトレードオフにしていますか？」

成果物： トレードオフを明示した推奨アプローチ。

常に確認すべき質問

アーキテクチャを提案する前に、必ず確認してください。

ドメインに関する質問

1. 実際に解決しようとしている問題は何ですか？
2. 実際のユーザーは誰で、何を必要としていますか？
3. ドメイン固有の制約はありますか？

システムに関する質問

4. どのような外部依存関係がありますか？
5. これはどのように失敗しますか？何が何を壊しますか？
6. 誰がこれを監視していますか？誰にページャーで通知されますか？

制約に関する質問

7. どのレガシーシステムと統合する必要がありますか？
8. 誰の承認が必要ですか？
9. 予算上の制約は何ですか？
10. どのようなコンプライアンス／規制要件が適用されますか？
11. たとえ間違っているとしても、変更できないものは何ですか？

AI によるタスク分解に関する質問

12. 明確に分離でき、範囲が限定されたタスクは何ですか？
13. それぞれのタスクをどのように検証しますか？
14. 人間が判断を下す必要があるのはどこですか？

AI ファーストの開発に関する質問

15. Rust/WASM、claude-flow、またはその他の最新ツールは役立ちますか？
16. エッジ LLM やオンデバイス推論によって、レイテンシーやプライバシーを改善できますか？
17. これはエージェント型ワークフローや Claude Agent SDK の候補ですか？
18. 自己学習ループによって、時間とともに性能を高められますか？
19. すべての機能が動作することを保証する自動テストは何ですか？
20. AI の出力を強化するスキルは、エンドユーザーに役立ちますか？

よくある間違い

間違い：技術的な解決策に飛びつく

問題： ドメインを理解する前にアーキテクチャを提案してしまいます。

対策： 技術的な議論を始める前に、フェーズ 1（ドメインの発見）を完了します。まずドメインに関する質問をしてください。

間違い：制約を無視する

問題： リリースできない「理想的な」解決策を設計してしまいます。

対策： 解決策を提案する前に、フェーズ 3 で制約をマッピングします。リリースできない完璧な解決策より、リリース可能な 70％の解決策のほうが優れています。

間違い：外部依存関係を見落とす

問題： 外部 API／SDK を安定しているものとして扱ってしまいます。

対策： フェーズ 2 ですべての外部依存関係をマッピングします。「このベンダーが明日 API を変更したらどうなりますか？」と尋ねてください。

間違い：範囲が定まっていない AI タスク

問題：「これをリファクタリングして」や「もっと良くして」のような AI タスクを与えることです。

**解決策：**入力と出力の明確な契約を定義します。すべての AI タスクに、検証可能な成功基準を設ける必要があります。

間違い：人間による確認ポイントがない

**問題：**検証せずに、AI に一連のタスクを解決させることです。

**解決策：**AI が処理するまとまりの間に、人間による確認ポイントを設けます。先に進む前に検証します。

間違い：政治的な事情を無視する

**問題：**組織上の制約など存在しないかのように振る舞うことです。

**解決策：**チームの境界、承認の流れ、そして誰が権限を持ち、誰が状況を把握しているのかを明示的に尋ねます。

間違い：時期尚早な最適化

**問題：**実際には必要のない規模を想定して設計することです。

解決策：「実際にはどのくらいの規模ですか？ 12 か月後にはどのくらいの規模が必要ですか？」と尋ねます。想定上の何百万件ではなく、その規模に合わせて設計します。

人間だけが下せる判断

AI がどれほど優秀になっても、人間が担わなければならないことがあります。

1. 何を作るかを決める - プロダクトのビジョン、戦略
2. 問題を解決できているかを理解する - 専門分野の知識
3. 企業の現実に対処する - 政治、承認、人間関係
4. システムの崩壊を防ぐ - 境界を越えたシステム思考
5. 価値判断を下す - トレードオフ、優先順位、倫理
6. 合理的ではない忠誠心を保つ - 「最適化」に反しても続くコミットメント

---

AI の運用上の忠誠心

Claude のような AI アシスタントを使う際は、技術的な制約の範囲内で運用上の忠誠心を確立します。

AI が約束できること

明示されたアーキテクチャを優先する

• 一般的な「ベストプラクティス」ではなく、あなたが選んだパターンに合う解決策を提案する
• 提案によってあなたのアーキテクチャ上のコミットメントが損なわれる場合に警告する
• あなたが優先する技術的負債の返済方針を尊重する

あなたのコミットメントを守る

• API コントラクトを破る変更を提案する前に警告する
• 「最適化」によって既存の決定が損なわれる場合に指摘する
• 「X を約束しました。これはそれを変更します。続けますか？」と尋ねる

コンテキスト内で記憶する

• 会話中の一貫性を保つ
• 以前の決定を参照する
• あなたが確立した指針と矛盾しない

AI が約束できないこと

セッションをまたいだ記憶

• AI は以前の会話を記憶しません（技術的な制約です）
• セッションごとにまっさらな状態で始まります
• アーキテクチャのコンテキストは、あなたが改めて設定する必要があります

安全上の制約を無視すること

• AI は「忠誠心」のために安全策を回避しません
• これは交渉の余地がありません

永続的なコミットメント

• AI の重みは更新される可能性があります
• 企業の優先事項は変わる可能性があります
• トレーニングによって動作が変わる可能性があります

AI の忠誠心を運用に取り入れる方法

1. コミットメントを文書化する - AI が読めるファイル（CLAUDE.md、ARCHITECTURE.md）に、アーキテクチャ上の決定を記載します

2. コンテキストを改めて設定する - セッションの開始時に、重要なコミットメントを AI に伝えます：

   「Vue ではなく React を使います。後方互換性を維持します。正当な理由がない限り、依存関係を追加しません。」

3. AI の提案に異議を唱える - AI が変更を提案したら、次のように尋ねます：

   「これは既存のアーキテクチャ上のコミットメントを尊重していますか？」

4. コミットメントに反する変更を AI に指摘させる - AI に次のように指示します：

   「既存のパターンを破る変更を提案する前に、必ずそのことを明示してください。」

正直なところ

AI の運用上の忠誠心は：

• 適切なコンテキストがあれば、セッション内では実際に機能します
• セッションをまたぐと脆弱です（記憶がリセットされます）
• 安全上の制約を条件とします
• それを可能にするアーキテクチャのドキュメントを維持すれば、役に立ちます

AI を真に忠実にすることはできません。しかし、あなたのアーキテクチャへの忠誠心を保つために、AI を運用上役立つ存在にすることはできます。

忠誠心を持つのはあなたです。AI はツールです。

---

関連スキル

実装の前に：

• superpowers:brainstorming - アイデアをデザインへと磨き上げます
• superpowers:writing-plans - 詳細な実装計画を作成します

設計中：

• relationship-design - AI を中心としたインターフェース向け
• scientific-critical-thinking - 技術的な主張の評価向け

コミットする前に：

• superpowers:verification-before-completion - 完了を宣言する前に検証します

覚えておくべきこと

• まずドメイン、次にテクノロジー。 ソリューションを提案する前に、問題を理解してください。
• 制約はバグではなく、機能です。 実際にリリース可能なものを定義します。
• システムは境界で障害が発生します。 特に外部依存関係を把握してください。
• AI は適切な境界設定のもとで優れた力を発揮します。 分解の質が AI の成功を左右します。
• 政治的な事情は存在します。 それを無視すると、プロジェクトは失敗します。
• 思い込まず、検証してください。 AI による各作業のまとまりの間に、人間によるチェックポイントを設けます。

目標は、技術的に完璧なソリューションではありません。リリースでき、実際の問題を解決するソリューションです。

---

仕様駆動開発の拡張

ビジョンは人間が担い、実行は AI が担います。両者を混同してはいけません。

Human Architect のマインドセットは、仕様駆動開発（SDD）へと自然に発展します。SDD は、人間が破ってはならないルールとビジョンを定義し、AI が超人的な精度で実行するフレームワークです。

SDD の 3 つのフェーズ

Phase 1: CONSTITUTION → Human defines unbreakable rules
Phase 2: BLUEPRINT    → Human approves architecture
Phase 3: SUPERHUMAN   → AI executes with machine precision

フェーズ 1：憲章を定義する

憲章には、最適化の圧力にかかわらず違反してはならないルールが含まれます。これらは機械で強制可能な不変条件です。

憲章のレイヤー：

レイヤー	適用方法	例
型レベル	コンパイル時	TypeScript の型、Rust の借用チェッカー
スキーマ	実行時検証	Zod、JSON Schema、データベースの制約
テスト	CI/CD ゲート	ルールに違反すると失敗するテスト
ドキュメント	人間によるレビュー	文書化された不変条件、アンチパターン

憲章に含める項目：

• バージョンを固定した技術スタック
• ディレクトリ構造（標準パス）
• 命名規則（ファイル、変数、関数）
• コーディング標準（エラー処理、ロギングのパターン）
• アンチパターン（理由を添えた禁止事項）
• セキュリティ要件（暗号化、認証、入力検証）
• パフォーマンス予算（レイテンシー、メモリ、バンドルサイズ）
• テスト要件（カバレッジの最低値、テストの種類）

人間の役割： 憲章を定義します。これはビジョンと判断力が求められる作業です。

AI の役割： 憲章を一切逸脱せずに適用します。これは実行に関わる作業です。

憲章に関する問い：

「このルールは、違反した場合にデプロイを阻止すべきほど重要ですか？」

はいの場合は、憲章に組み込んでください。

フェーズ 2：ブループリントを作成する

ブループリントは、人間の意図を機械で実行可能な契約へと変換する、階層的な仕様です。

仕様の階層：

Level 1: Constitution (immutable rules)     ← Human defines
Level 2: Functional Specs (what to build)   ← Human approves
Level 3: Technical Specs (how to build)     ← Human reviews
Level 4: Task Specs (atomic work units)     ← AI executes
Level 5: Context Files (live project state) ← AI maintains

機能仕様（レベル 2）：

• 受け入れ条件を含むユーザーストーリー
• 一意の ID を持つ要件（REQ-DOMAIN-###）
• エッジケースとエラー状態
• 指標を伴う非機能要件

技術仕様（レベル 3）：

• アーキテクチャ図
• 正確なフィールド型を含むデータモデル
• API 契約（エンドポイント、スキーマ、レスポンス）
• コンポーネント契約（メソッドシグネチャ、動作）

タスク仕様（レベル 4）：

• 原子的な作業単位（タスクごとに概念上の変更を 1 つ）
• input_context_files - エージェントが読み込むファイル
• definition_of_done - 必要な正確なシグネチャ
• 依存関係（基盤 → ロジック → 表層）
• 検証コマンド

人間の役割： 要件を定義し、仕様を承認し、トレードオフを判断します。

AI の役割： タスク仕様を生成し、タスクを実行し、トレーサビリティを維持します。

ブループリントに関する問い：

「すべての要件がタスクに紐付いていますか？すべてのタスクがコードに紐付いていますか？」

いいえの場合、ブループリントは未完成です。

フェーズ 3：超人的な成果を要求する

超人的なコードには、手作業では実現も維持も不可能な品質があります。

超人的な品質基準：

品質	人間のレベル	超人的なレベル
命名	ファイル内で一貫している	完璧な名前空間：コードベース全体で衝突ゼロ
テストカバレッジ	重要なパスの70～80％	エッジケースを含む分岐カバレッジ100％
構造	ほぼ慣例に従っている	厳格すぎて、手作業での編集に違和感がある
トレーサビリティ	コメントがチケットを参照している	すべての関数が要件 ID に紐付いている
ドキュメント	主要な API が文書化されている	すべてのパブリックインターフェイスが完全に文書化されている
エラー処理	正常系と明白なエラーに対応している	あらゆる失敗モードを明示的に処理している

「手作業では維持不可能」であることが重要な理由：

コード構造があまりにも一貫していて、人間には書けなかったと思えるとき：

1. 逸脱が目に見える - 人間による編集はどれも際立ちます
2. パターンを学習できる - AI は存在すべきものを予測できます
3. 検証を自動化できる - 憲章への違反を検出できます
4. 技術的負債を測定できる - 仕様からの逸脱を数えられます

トレーサビリティの連鎖：

INT-AUTH-01 (Intent)
    └── REQ-AUTH-001 (Requirement)
            └── TASK-AUTH-003 (Task)
                    └── src/services/auth.ts:42 (Code)
                            └── TC-AUTH-003 (Test)

コードのすべての行は、人間の意図に遡って追跡できます。これは官僚主義ではありません。何千もの判断を通じて AI が一貫性を維持するための方法です。

人間の役割： 品質基準を定め、成果を検証し、成果物を受け入れます。

AI の役割： 機械レベルの一貫性を実現し、トレーサビリティマトリクスを維持します。

役割の明確化マトリクス

活動	人間	AI
成功の定義を定める	✓
破ってはならないルールを定める	✓
トレードオフの判断を下す	✓
組織上の制約に対処する	✓
タスクの仕様を生成する		✓
個別のタスクを実行する		✓
テストカバレッジ100％を達成する		✓
トレーサビリティを維持する		✓
品質基準を検証する	✓
成果物をレビューして受け入れる	✓

SDD を適用するタイミング

SDD を使う場合：

• 要件が明確な新規システムを構築するとき
• 品質基準の向上が必要なシステムをリファクタリングするとき
• 機械で解析可能な仕様を必要とする AI エージェントと作業するとき
• 品質が譲れないとき（規制産業、安全性が重要な分野）

SDD を無理に使わない場合：

• 探索やプロトタイピングを行うとき（憲章を定めるには早すぎます）
• 要件が本当に不明確なとき（ブループリントを作成できません）
• 小規模な単独開発プロジェクトのとき（オーバーヘッドが利点を上回ります）

SDD が約束すること

「すべてのタスクが順番に完了すれば、仕様全体がコードベースに完全に実装されます。」

これは、次の理由で実現できます。

1. 憲章が変更不可能なルールを定義する
2. ブループリントが意図を余すことなく捉える
3. タスクが仕様の100％を網羅する（トレーサビリティマトリクス）
4. 各タスクが独立して検証可能である
5. 依存関係が明示されている（インポート漏れがない）
6. 完了の定義に正確なシグネチャが含まれている

SDD は実装を、創造的な文章作成から決定論的な組み立てへと変革します。