『生成AI時代のクレデンシャルとパーミッション設計 — Claude Code を起点に』を書きます。個人開発者向けにコメント募集

　Claude Code に作業を任せて席を外し、戻ってきたらコマンド許諾待ちで止まっていた。そんな経験ありませんか。

　かといって全部 allow にしてしまえば、.env 読み出しや bash 任意実行のリスクが跳ね上がります。「席を外せる自律性」と「無制限許可の危険」のあいだに、どう線を引くか。この問いを 8 章で具体化する本『生成AI時代のクレデンシャルとパーミッション設計 — Claude Code を起点に』を、姉妹書と同時に 2026 年 11 月発売予定で執筆中です。

speakerdeck.com

　このエントリは上記 Speaker Deck の補足です。なぜこの本を書くのか、何を扱って何を扱わないのか、執筆中にコメントで聞きたいことを書きます。

なぜこの本を書くか

　きっかけは、自著を音声化する個人プロジェクトです。AWS Polly に Claude Code から API を叩かせて朗読音声を生成する、という小さなタスクです。

　CLI に AWS SSO から取得した一時認証情報を設定して、claude を起動しました。IAM ロールの有効期限は 60 分。作業の途中でこの期限が切れて、Polly が呼び出せなくなりました。再開するには手元に戻って SSO 経由の認証を踏み直す必要があります。

　長めの作業を任せて席を外したかったのに、認証情報の有効期限が壁になって止まってしまいます。「席を外せる自律性」を阻むのは、許諾プロンプトだけではない。クレデンシャルの寿命設計でも同じ構図で詰まる、と気付いたのがこのときでした。

　ここから本書の問いが固まりました。AI に何をどこまで任せるかは、「どんな権限（パーミッション）を渡すか」と「どんな認証情報（クレデンシャル）を渡すか」をペアで設計しないと、片方だけ整えても穴が残ります。

本書の問い席を外せる自律性と無制限許可の危険のあいだ

　本書の問いは一文で書けます。

「席を外せる自律性」と「無制限許可の危険」のあいだで、どこに線を引くか。

　この問いには二つの懸念に紐づきます。

許諾待ちで止まる事故。Claude Code を起動して席を外したのに、最初の Bash 実行で許諾プロンプトが出て、戻るまで何も進んでいない
過剰許可で壊れる事故。bypassPermissions モードで放任した結果、.env が読まれた、想定外のファイルが消された、indirect prompt injection で外部 API が叩かれた

　Claude Code の settings.json / hooks / sandbox / コンテナ / シークレット集中管理 / MCP 設定の各層を、この問いに沿って具体化していくのが本書の構成です。

本書のスコープハーネスのうち security 軸に絞る

　本書はハーネスエンジニアリングの security / isolation / credential 軸に特化します。

　「ハーネスエンジニアリング」は Mitchell Hashimoto が 2026 年 2 月に提唱して急速に広がった用語で、Agent = Model + Harness、つまりモデル以外のすべてを harness と呼ぶ枠組みです。subagents / context compaction / feedback loop / orchestration など多面に及びますが、本書はそのうち security / isolation / credential 軸に絞ります。品質や効率を上げる harness 設計は対象外です。

　章立ては以下の通り。

前書き個人開発で Claude Code を使う前提と本書 stance
ch.1 クレデンシャル × パーミッション地図
ch.2 パーミッション設計（settings.json / hooks / CLAUDE.md / auto mode）
ch.3 隔離戦略（Sandbox / コンテナ / 機微ファイル / データ分類 4 levels）
ch.4 API 経路と AWS 連携（Anthropic API vs Bedrock）
ch.5 シークレット集中管理（中心章、AI に渡す / 渡さない設計）
ch.6 外部リソース連携（MCP と外部サイト参照）
ch.7 個人の環境を再利用可能にする（小規模共有まで）
ch.8 セキュリティと監査
付録 settings.json テンプレ、.mcp.json テンプレ、Bedrock レシピ、業界フレーム照合

　主読者は、Claude Code を個人で日常的に使っている開発者です。ch.7 では作り込んだ環境を友人や副業先と共有するレベルまで扱いますが、組織導入の管理運用は本書の主軸ではありません。

中心章 ch.5 AI に渡す / 渡さない設計

　中心章は ch.5 です。本書独自のフレームを 2 つ置いています。

　一つ目は、AI が秘密に触れる程度の 3 段階モデル。

第 1 段階直読み型 AI が秘密値を直接読む（.env 直書き、~/.aws/credentials を素のまま使う、等）
第 2 段階限定直読み型 AI は読むが、影響範囲を mount 制御 / 短命化 / スコープ制限で削る
第 3 段階非直読み型 AI に秘密値を渡さず、操作だけを渡す（credential broker、Bedrock 経由、MCP-as-broker）

　「どこに置くか」ではなく「AI に読ませるかどうか」で credential 設計を整理する軸です。本書では 3 段階目を目指しつつ、現実解として 2 段階目を Sandbox / コンテナと組み合わせて受け止める設計を提示します。

　二つ目は、本書本命の broker を AWS Secrets Manager + aws-vault 一本に絞った話。1Password と HashiCorp Vault も最初は候補でした。ただ本書の問い（席を外せる自律性）に照らすと、個人ユースで自動リフレッシュが回って構築負荷・コストも許容範囲に収まるのは（自分の中では）AWS Secrets Manager + aws-vault しかなかった、という選定です。

　1Password を試した経緯と、用途を絞って今も使っている話は、別エントリにまとめてあります。

blog.takuros.net

　このエントリの結論「個人プランの op signin は 30 分セッションで、無人バッチや短命トークンを伴う長時間タスクで壁に当たる」が、ch.5 で本命を AWS Secrets Manager に絞った理由の一つです。