Upgrade to Pro — share decks privately, control downloads, hide ads and more …

AIアーキテクト_読書メモ_要点整理

 AIアーキテクト_読書メモ_要点整理

Avatar for Masahiro Muto

Masahiro Muto

November 03, 2026

More Decks by Masahiro Muto

Other Decks in Technology

Transcript

  1. 『AI アーキテクト』 読書メモ AIが作る時代ほど、設計する人が要る AIが得意なのは生成や実行。目的や責任まで、自動的に決まるわけではありません。 01 02 03 目的を決める 境界を引く

    確かめる仕組みを作る 誰の、どんな問題を解くのか。 やらないことも決める。 AIに任せる判断と、 人が引き受ける判断を分ける。 個人の確認だけに頼らず、 テスト・評価・監視を組み込む。 「がんばって確認する」から、「仕組みで品質を支える」へ。 考え方と実務のポイントを、初めて読む人向けに整理 02
  2. 『AI アーキテクト』 読書メモ 開発の重心は、前後の仕事にも移る 生成AIで実装の負担が減るほど、問題の捉え方と結果の確かめ方が大切になります。 01 02 03 04 問題理解

    計画 実行 振り返り 何が本当の問題かを考える 進め方と受入条件を決める AIと一緒に作り、動かす 結果を評価し、次に直す 以前は「作る」ことに多くの時間がかかりました。これからは、作ったものが本当に役立つかまでを含めて設 計します。 考え方と実務のポイントを、初めて読む人向けに整理 03
  3. 『AI アーキテクト』 読書メモ アーキテクチャの型は、使う場面から選ぶ 名前のついた設計パターンは、設計の意図を短く共有するための共通言語になります。 レイヤード 既存の仕組みにAI機能を足す イベント駆動 複数のAgentを非同期につなぐ パイプライン

    生成と検証を段階ごとに分ける スペースベース 共有の作業場所で成果を受け渡す マイクロカーネル ツールや機能をプラグインで増やす マイクロサービス 役割ごとに独立して運用する サービスベース サービス指向 大きな単位で段階的に導入する 共通の入口で権限や連携を管理する 一つに決める必要はありません。必要な型を組み合わせて使います。 考え方と実務のポイントを、初めて読む人向けに整理 04
  4. 『AI アーキテクト』 読書メモ 最初から大きな仕組みを作らない 使う人や用途が増えたときに、必要な構造を足していけば十分です。 STEP 0 1 AI機能を1つ足す まず既存システムに組み込む

    STEP 0 2 生成と検証を分ける 品質をチェックできるように する STEP 0 3 サービスとして分け る 機能ごとに運用できる形にす る STEP 0 4 共通の入口を設ける S TEP 0 5 認証・権限・監査をそろえる Agent同士をつなぐ 非同期連携と成果物の共有 複雑さが増える前から、複雑な設計を持ち込まない。 考え方と実務のポイントを、初めて読む人向けに整理 05
  5. 『AI アーキテクト』 読書メモ やり直せる部分と、やり直しにくい部分を分ける すべてを初めに固めるのではなく、後から直しにくいところに設計時間を使います。 使いながら調整しやすい 初めに境界を決めておく プロンプトの書き方 保存するデータの形と粒度 使うモデル

    外部公開するAPIや契約 渡すコンテキスト 認証・権限の境界 評価基準や閾値の調整 生成物や判断の監査記録 まず守る線を決め、作りながら直せる余地を残す。 考え方と実務のポイントを、初めて読む人向けに整理 06
  6. 『AI アーキテクト』 読書メモ AI駆動開発は、道具よりも工程を変える 今までの開発工程を捨てるのではなく、それぞれの工程でAIの使いどころを考え直します。 01 02 03 04 要求・要件

    設計 実装・テスト 運用・改善 なぜ必要かを考える。 優先順位と、やらないことを 決める。 読み違えにくい仕様と 受入条件を用意する。 小さく生成し、その都度 検証して直す。 利用状況や失敗例から 次の改善につなげる。 作ったら終わりではなく、動かして確かめ、次に生かす。 考え方と実務のポイントを、初めて読む人向けに整理 07
  7. 『AI アーキテクト』 読書メモ テストを先に書くと、AIへの指示も明確になる 「何ができれば完成か」を先に決める。テストが、仕様の一部になります。 Red Green Refactor 失敗するテストを用意 AIが最小限の実装を作る

    動作を保って整える 例えば 「申請額が上限を超えたら、承認できない」 この条件をテストにしてから実装する。テスト自体が正しいかは人が確認する。 テストが間違っていれば、正しく作っても望んだものにはなりません。 考え方と実務のポイントを、初めて読む人向けに整理 08
  8. 『AI アーキテクト』 読書メモ 品質は「本番前」と「本番後」の両方で見る AIの出力は揺れます。リリース時だけではなく、使われ始めてからも確かめます。 本番前:オフライン評価 本番後:オンライン評価 代表的な質問と期待する結果を集め、 変更のたびにまとめて試す。 実際の利用状況を見ながら確かめる。

    ・正答率や根拠の妥当性 ・危険な出力がないか ・以前より悪くなっていないか ・利用者が聞き直していないか ・回答を修正していないか ・処理時間、失敗、コスト ・新旧の方式を比べた結果 見つかった失敗を評価ケースに加え、次の変更で再発しないか確かめる。 考え方と実務のポイントを、初めて読む人向けに整理 09
  9. 『AI アーキテクト』 読書メモ 外から来た文章を、命令として扱わない 攻撃は質問欄だけでなく、検索した文書やツールの実行結果にも紛れ込みます。 利用者の入力 検索した文書 ツールの結果 Webページ 外部の文章は「参考情報」。システムへの指示ではない。

    呼べるツールを限定する データを見せる範囲を絞る 重要な操作は承認を挟む 「文書に書いてあったから実行した」を起こさないための設計です。 考え方と実務のポイントを、初めて読む人向けに整理 10
  10. 『AI アーキテクト』 読書メモ AI Agentは、止め方まで設計しておく 同じ失敗を繰り返すと、時間と費用だけが増えます。 失敗 → 再試行 →

    また失敗 → 再試行… 反復回数 トークン数 処理時間 費用 連続失敗 うまくいかないときの順序例 安全な別モデルへ 機能を減らす 人に引き継ぐ できないと伝える 使ったことのない避難経路は、本番で突然動きません。先に試しておきます。 考え方と実務のポイントを、初めて読む人向けに整理 11
  11. 『AI アーキテクト』 読書メモ データは「原本」「属性」「意味」を分けて持つ 画像・音声・文書など、文字だけではない情報もAIの知識になります。 原本を保管 属性を別に管理 検索のために整理 PDF・画像・動画・音声など 後から確かめられる形で残す

    作成日・出典・権限など 検索や表示の条件に使う 全文検索・ベクトル検索 知識グラフを組み合わせる 知識グラフでは「同じ人物・同じ会社か」を慎重に見分ける。 別人を同一人物として結びつけると、誤った関係が広がるためです。 検索の精度だけでなく、出典と権限をたどれることも大切です。 考え方と実務のポイントを、初めて読む人向けに整理 12
  12. 『AI アーキテクト』 読書メモ Agentは「頭脳」「動かし方」「作業場所」に分ける モデルだけを交換しても、仕事全体の進め方まで変えられるとは限りません。 モデル 言葉を理解し、候補や手順を考える GPT / Claude

    / Gemini など ハーネス ツールの利用、再試行、記録、予算を管理 Agent Runtime / Coding Agent など 実行環境 ファイル、ネットワーク、権限を隔離する Container / microVM / Sandbox など 役割を分けると、モデル変更・制御の改善・実行環境の拡張を別々に進められます。 考え方と実務のポイントを、初めて読む人向けに整理 13
  13. 『AI アーキテクト』 読書メモ 複数のAgentには、役割と受け渡しの決まりが要る たくさん動かすことより、成果をどう確認して取り込むかが重要です。 群れを動かす4つの層 実装と確認を分ける 実行パターン 役割分担・進め方 稼働環境

    Agentごとの隔離 ハーネス 並列度・再試行・予算・記録 実装Agent(複数) レビューAgent 人間が最終判断 統合 成果物を本流へ戻す 先に決める契約: 成果物の形式 / 完了条件 / 読み書き・実行の権限 Agent同士が同じ結論でも、それだけで正しいとは限りません。 考え方と実務のポイントを、初めて読む人向けに整理 14
  14. 『AI アーキテクト』 読書メモ 人が関わる深さは、仕事のリスクで変える 何でも人が承認すると遅くなり、何も見ないと危険です。 実行前に承認 必要なときに介入 事後に監査 Human-in-the-loop Human-on-the-loop

    Human-out-of-the-loop 送金、社外送信、 本番環境の重要な変更 AIの通常処理を監視し、 例外や異常だけ確認 低リスクで、取り消しや 検証ができる定型処理 人には人の得意があり、モデルにも得意・不得意がある。仕事に合わせて組み合わせる。 人を減らすことが目的ではなく、判断が必要な場所に人を置くこと。 考え方と実務のポイントを、初めて読む人向けに整理 15
  15. 『AI アーキテクト』 読書メモ PoCから本番へは、段階ごとに違う問いを立てる デモが動くことと、業務で使い続けられることは別です。 01 02 03 04 PoC

    パイロット 本番化 展開 技術的にできるか 業務の役に立つか 続けられるか 広げられるか 仕組みと前提を確認 現場で効果を試す 安全性・品質・運用を整える 共通部品と基準を用意 各段階のあいだに、進む基準と止まる基準を置く。撤退や凍結も、きちんとした判断です。 後から判断基準を作ると、かけた費用が次の判断を鈍らせます。 考え方と実務のポイントを、初めて読む人向けに整理 16
  16. 『AI アーキテクト』 読書メモ AIアーキテクトが設計する、6つのこと システムの形だけでなく、AIと人が仕事を続けられる条件を整えます。 01 02 03 文脈 境界

    実行 何のために、何を知るべきか 何をAIに任せ、何を守るか 安全に動かし、止められるか 04 05 06 検証 学習 展開 結果をどう確かめるか 失敗を次の改善に使えるか ほかの仕事にも広げられるか AIを自由に動かすために、先に構造を整える。 考え方と実務のポイントを、初めて読む人向けに整理 17