Claude Codeの初期設定｜AIエージェントに任せる前の4観点

Claude Codeを業務に入れた初日、いちばん多い質問は「最初に何を設定すればいいのか」です。入れた直後から動いてしまうので、設定を飛ばしても仕事は進みます。困るのは、進んだあとです。

あとから権限を絞ろうとすると、すでに走った操作の後始末が先に来ます。設計を考える時間は、そこで消えます。初日に手を動かす価値は、便利になることではなく、この後始末を作らないところにあります。

この記事は、初日に固める観点を4つに絞ります。権限、フック、ルールファイル、記録です。根拠は、Claude Codeの公式ドキュメントと、運営元WEBMARKSが実際に使っているsettings.jsonとフックの抜粋です。

進行役は3人です。若葉さん（Web担当2年目）が用語のそもそもを聞き、高梨課長が自分の手で設定を書き、鈴木さん（本誌監修）が答えます。

01Claude Codeの初期設定は、AIエージェントに任せる前の何を決める作業なんですか？

若葉さん

若葉さんの発言

初期設定というと、アカウントを作ってフォルダを開くところまで、というイメージなんですが。

鈴木さん

鈴木さんの発言

それは箱を置いただけですね。設定というより、鍵をどこに掛けるかを決める作業だと思ってください。

若葉さん

若葉さんの発言

鍵、ですか。

鈴木さん

鈴木さんの発言

ええ。開けっぱなしでも仕事は回ります。ただ、閉め忘れた場所をあとから探すのは骨が折れます。最初に4か所だけ決めておきます。

決めるのは4つです。権限は、許可・確認・拒否をどう配分するか。フックは、実行の直前と直後に何を挟むか。ルールファイルは、AIに最初に何を読ませるか。記録は、案件と作業ログをどうつなぐか。この4つは、初日に枠だけ決めておけば足ります。

読むときに効いてくるのは、右の列です。上の2つは仕組みとして働き、3つ目は判断材料にとどまります。同じ「設定」という言葉で並んでいても、効き方はここで割れます。

止めたい操作を、効き方の弱いほうに書いてしまう。初期設定でいちばん多い取り違えは、この1点に集まります。

02Claude Codeの初期設定を後回しにすると、AI導入のどこで詰まるんですか？

高梨課長

高梨課長の発言

使いながら少しずつ整えていく、という進め方ではだめでしょうか。

鈴木さん

鈴木さんの発言

だめではありません。ただ、順番が入れ替わります。あとから足すと、すでに動かした操作の後始末が先に来ます。

高梨課長

高梨課長の発言

後始末というと。

鈴木さん

鈴木さんの発言

消えたファイルを戻す、押してしまった操作を取り消す。そこに時間を使うと、設計を考える時間が残らないんです。

初期設定を後回しにしても、最初のうちは何も起きません。起きないから、そのまま使い続けます。線を引くのは、たいてい何かが起きたあとです。

そのときには、判断の材料が減っています。目の前の後始末に追われている状態で、任せる範囲を落ち着いて決められる人は多くありません。急いで引いた線は広すぎるか狭すぎるかのどちらかになり、また引き直すことになります。

初日に決めておくと、この順番が逆になります。何も起きていない時間に線を引き、起きたときには止まる。AI導入を社内へ広げる段になっても、説明する材料が先に手元にあります。

03権限の初期設定では、AIエージェントに何をさせない側から書くんですか？

権限は、許可（allow）・確認（ask）・拒否（deny）の3種類のルールで構成されます。評価順序は常にdeny→ask→allowの固定順で、ルールの詳しさが順序を変えることはありません（出典: Claude Code公式ドキュメント）。

順序が固定という一文は、書き方を1つに縛ります。広いdenyルールは、一致する狭いallowルールがあっても優先してブロックします（出典: 同）。つまり、denyの中にallowの例外を混ぜることはできません。例外を作りたいなら、denyの記述そのものを狭めます。

そもそも承認が要るかどうかは、ツールの種類でも変わります。

書き出すときは、拒否からです。取り返しがつかない操作を先に並べ、そのあとで人に見せたい操作をaskへ移します。allowは最後で構いません。

04Claude Codeの初期設定として、自社のsettings.jsonでは、AIエージェントに何をさせないと決めているんですか？

考え方だけでは配分が決まらないので、実際に運用している中身を出します。

自社のsettings.jsonでは、denyにBash(rm -rf*)とBash(git push --force*)、Read(**/.env)を置いています。askにはBash(git push*)とEdit(CLAUDE.md)、Write(00_intake/**)を置いています（2026-07-28時点の設定ファイルを確認）。

{
  "permissions": {
    "deny": ["Bash(rm -rf*)", "Bash(git push --force*)", "Read(**/.env)"],
    "ask": ["Bash(git push*)", "Edit(CLAUDE.md)", "Write(00_intake/**)"],
    "allow": ["Bash(mdfind *)", "Bash(launchctl list *)"]
  }
}

並べ方には理屈があります。取り返しがつかない操作と、正本ファイルへの書き込みを、最初からこの2段に分けています。allowには、繰り返し使っても安全な操作だけを置きます。allowを広げすぎると、denyの見直しが後回しになります。

自社の並びをそのまま写す必要はありません。写してほしいのは、拒否と確認を先に埋めて、許可を最後に回すという順番のほうです。

05Claude Codeの初期設定で、フックは、AI社員が踏み込みそうな操作をどこで止めているんですか？

高梨課長

高梨課長の発言

権限で書ききれない条件は、どこに書けばいいんでしょう。中身を見て判断したい場合です。

鈴木さん

鈴木さんの発言

そこはフックの担当です。ツールを呼ぶ手前でコードが動いて、通すか止めるかを返します。

高梨課長

高梨課長の発言

権限より強いということですか。

鈴木さん

鈴木さんの発言

強いというより、見える範囲が違います。書式では表せない条件まで見られるのがフックです。

フックは、発火するタイミングで3つの頻度に分かれます（出典: Claude Code公式ドキュメント）。

危険な操作を止めるなら、使うのはPreToolUseです。書き方はsettings.jsonのhooksキーに、matcher（対象ツール名）と実行するコマンドを並べる形です。公式ドキュメントに載っている例は、Bashコマンドの中身を読み、rm -rfを見つけたらdenyを返すスクリプトです。

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "Destructive rm -rf blocked"
  }
}

返せる判定はallow（通す）・deny（止める）・ask（人に聞く）の3通りです（出典: Claude Code公式ドキュメント）。ここで気をつけたいのは、フック側でdenyにしても、残りの操作は通常の権限設定に従うという点です。自動で進めたい操作は、別途allowに書いておきます。

自社のPreToolUse(Bash)フックは、機密ファイルの中身を表示しようとする操作や、外部サービスへ送ろうとする操作を判定して止めます。正本フォルダへの直接コピーや、強制pushも同じ扱いです（2026-07-28時点のフックコードを確認）。CLAUDE.mdに書いた指示より効き方が強いので、止めると決めた操作はここへ移します。

06ルールファイルには、Claude Codeの初期設定としてAIエージェントに読ませたいことをどこまで書くんですか？

CLAUDE.mdは、セッション開始のたびにClaude Codeが読み込むMarkdownファイルです。置き場所は4段階に分かれ、この順で読み込まれます（出典: Claude Code公式ドキュメント）。

段が分かれているのは、決める人が違うからです。組織として揃えたい話と、手元の都合を、同じファイルへ書かないための仕組みです。

自社のCLAUDE.mdは15章構成（§0〜§14）です。Vaultのフォルダ構造、秘匿性の3段階管理、成果物の振り分けルール、送信や公開を止める人間ゲートまでを章立てにしています。

07Claude Codeの初期設定で書いたルールファイルが長くなると、AI活用のときどんな不都合が出るんですか？

長さには目安があります。公式ドキュメントは、200行を超えるとコンテキスト消費が増え、指示への追従が下がると明記しています。長いルールは.claude/rules/へパスごとに分割する設計を勧めています（出典: Claude Code公式ドキュメント）。

分ける利点は、短くなることだけではありません。その場所を触るときにだけ読ませる形になるので、いま関係のない決めごとが混ざりません。初日は、分ける先のフォルダを用意しておくところまでで足ります。

似た役割にauto memoryがありますが、書き手が違います。CLAUDE.mdは人間が書く指示で、auto memoryはClaudeが訂正から学んで書く覚え書きです。初期設定の段階では、まずCLAUDE.mdへ「毎回説明し直したくないルール」を書き、auto memoryは運用しながら育つのに任せます。

すでにAGENTS.mdを使っている場合、Claude CodeはAGENTS.mdを直接読みません。CLAUDE.mdから@AGENTS.mdという書き方でインポートすれば、二重管理をせずに済みます（出典: Claude Code公式ドキュメント）。

08記録の初期設定をしておくと、AIエージェントは中断からどう戻れるんですか？

若葉さん

若葉さんの発言

権限もフックも書いたのに、記録まで初日にいるものでしょうか。

鈴木さん

鈴木さんの発言

設定は「やらせない」を決めるものですよね。記録は「どこまでやったか」を残すものです。役目が違います。

若葉さん

若葉さんの発言

途中で止まったときのため、ということですか。

鈴木さん

鈴木さんの発言

そうです。セッションは落ちます。落ちたあとに戻れるかどうかは、初日にどこへ書くと決めたかで変わります。

設定ファイルや権限を固めても、セッションが途中で落ちれば「どこまで終わっていたか」が分からなくなります。Claude CodeはSessionStartフックで再開時に文脈を渡せるので、記録の置き場をここへ接続するのが定石です（出典: Claude Code公式ドキュメント）。

自社では、作業の状態を1つの台帳ファイルに書き、案件ごとにIDを振っています。着手したら「進行中」、人の判断待ちに来たら「人間ゲート待ち」、終わったら「完了」と状態を更新します。SessionStartフックが起動のたびにこの台帳を読むので、クラッシュや再起動で途中終了しても、次のセッションが状態から再開できます。

記録を「あとで書く」運用にすると、途中で終わったセッションの分だけ記録が抜けます。落ちるときは、終了処理を待ってくれないからです。作業の節目ごとに更新する運用にしておけば、抜けは起動時のフックが機械的に拾います。

初期設定の段階でやることは2つだけです。案件を識別するIDの採番ルールを決めること、状態を書く場所を1つに絞ることです。置き場を増やすほど、どれが正本か分からなくなります。

09Claude Codeの初期設定でつまずくのは、AI導入のどのあたりなんですか？

つまずき方には型があります。多いものを5つ挙げます。

1つ目は、CLAUDE.mdに書けば止まると思い込むことです。権限ルールはClaude Codeが機械的に適用しますが、CLAUDE.mdの指示はClaudeの判断に委ねられます（出典: Claude Code公式ドキュメント）。止めると決めた操作は、PreToolUseフックか権限のdenyへ書きます。

2つ目は、curlのURL制限を文字列一致で書くことです。オプションの位置やリダイレクトで、簡単にすり抜けます（出典: 同）。止めたいなら、curl自体をdenyにして、WebFetch(domain:許可ドメイン)で絞ります。

3つ目は、allowルールを書いたのに効かない場面です。プロジェクトの.claude/settings.jsonにあるallowルールには条件があります。そのフォルダのworkspace trustダイアログを承認するまで、ルールは適用されません（出典: 同）。初回起動時のダイアログを見落としていないかを確かめます。

4つ目は、Write(docs/**)でファイルを保護したつもりになることです。ここは実際には効きません。ファイル権限のチェックはEdit(path)とRead(path)のルールしか見ないためです（出典: 同）。保護したい対象はEdit(パス)で書き直します。

5つ目は、modelを設定ファイルで変えてすぐ使えると思うことです。permissionsとhooksはホットリロードされますが、modelとoutputStyleはセッション再起動まで反映されません（出典: 同）。設定を変えた直後に動きが変わらなくても、壊れているわけではありません。

10Claude Codeの初期設定が効いているかは、AI活用を始める前にどう確かめるんですか？

書き終えたら、自分の環境のsettings.jsonとCLAUDE.mdを開いて突き合わせます。見るところは決まっています。

• 権限：denyに「取り返しがつかない操作」を先に列挙したか（rm -rf・force push・.env読み取りなど）
• 権限：askに「正本ファイルへの書き込み」を列挙したか
• フック：PreToolUse(Bash)で、CLAUDE.mdに書いただけの禁止事項をコードでも止めているか
• フック：どのスコープ（ユーザー・プロジェクト・ローカル）に登録したか、意図どおりか
• ルールファイル：CLAUDE.mdが200行を超えていないか。超えているなら.claude/rules/へ分割したか
• ルールファイル：/contextで、CLAUDE.mdが実際に読み込まれているかを確認したか
• 記録：案件を識別するIDの採番ルールを決めたか
• 記録：作業状態を書く正本を1つに絞ったか

読み返して納得するのと、動かして確かめるのは別ものです。とくにルールファイルの行は、/contextを打てばその場で答えが出ます。読み込まれていないファイルへ何を書いても、効き目はありません。

11初期設定のあと、AI社員として任せる範囲はどう広げていくんですか？

初日に引いた線は、そのまま固定するものではありません。permissionsとhooksはホットリロードされるので、随時見直せます（出典: Claude Code公式ドキュメント）。広げるときも、狭めるときも、その場で反映されます。

広げ方には順番があります。まずaskで通した操作のうち、毎回同じ判断をしているものを見つけます。人が見ても結果が変わらない操作は、allowへ移す候補です。逆に、askのまま残す価値があるのは、判断が分かれる操作だけです。

denyは最後まで残します。取り返しがつかない操作は、慣れによって安全になるわけではないからです。狭めるとしても、記述そのものを絞る形にします。穴を開けるのではなく、線を引き直す、という順番です。

ルールファイルと記録も、育て方が決まっています。CLAUDE.mdへは「毎回説明し直したくないルール」だけを足し、それ以外はauto memoryが運用の中で育つのに任せます。記録は、節目ごとに更新する習慣が続いているかだけを見ます。

12よくある質問

13まとめ｜今日やる3つのこと

初期設定は、線を引く場所を決める作業です。仕組みで効く場所から順に手をつけます。