はじめに(導入)
Claude Codeは名前の通りコードを書くためのツールだが、公式ドキュメントは出力スタイル(output styles)のページで「Adapt Claude Code for uses beyond software engineering(ソフトウェアエンジニアリング以外の用途にも適応させる)」とはっきり書いている。つまり公式自身が「非エンジニアの日常タスクにも使える」ことを前提にしている。
問題は、コードを書かない人がいきなり使うと「何が安全で、何が危険な操作なのか」が分からないことだ。この記事では、コードを一切書かずに完結する実務タスク(ファイルの内容ごとの自動整理)を題材に、①権限モードで安全に試す→②実際に実行する→③出力スタイルで説明の詳しさを変える、という3つの機能を1つの実務フローに統合し、実際に手を動かして確認した挙動と、ドキュメント通りにいかなかった箇所を報告する。
前提: 実行したのはClaude Code v2.1.270(claude --versionで確認)。以下の例はすべて/tmp以下の使い捨てフォルダで検証しており、読者の実データを直接操作するものではない。
手順とコピペ用プロンプト集
ステップ0: いま自分がどのモードで動いているかを確認する(無料・1秒未満で完結)
非エンジニアがまず知るべきなのは「Claude Codeには”確認してから実行するモード”と”確認なしで進めるモード”がある」という一点だけだ。公式ドキュメント(Choose a permission mode)によると、主なモードは次の通り。
| モード | 動き | 向いている場面 |
|---|---|---|
default(Manual) |
読み取り以外はすべて確認を求める | 慣れないうちの標準 |
plan |
調査・計画は行うが編集はしない | 「何をするか」だけ先に見たいとき |
acceptEdits |
ファイルの作成・編集・移動は確認なしで実行 | 内容を後でまとめて確認する運用 |
auto |
ほぼ全自動(別のAIが安全性を審査) | Pro/Max/Teamプランの既定値 |
bypassPermissions |
確認なし・審査なし | 隔離環境専用。非エンジニアには非推奨 |
コピペ用プロンプト①(前提条件: Claude Codeがインストール済みであること。課金なし・外部リソース構築なし・1秒未満で完結):
/output-style
期待される結果: 現在の出力スタイル名と選択可能な一覧がその場で表示される。実際に手元(v2.1.270)で実行すると次のように返ってきた(total_cost_usdは0で、API課金が一切発生しないローカルコマンドであることも実測で確認できた)。
Output style: default
Available styles:
- default (current)
- Proactive: Claude executes immediately, minimizes interruptions, and prefers action over planning
- Concise: Claude responds tersely, leading with results and skipping preamble and narration
- Explanatory: Claude explains its implementation choices and codebase patterns
- Learning: Claude pauses and asks you to write small pieces of code for hands-on practice
Usage: /output-style <style>
成功判定: 一覧に4つの組み込みスタイル名(Proactive/Concise/Explanatory/Learning)が表示されれば、Claude Codeが正常に起動し、追加の設定なしでいつでもスタイルを切り替えられる状態にあることが分かる。
ステップ1: plan modeで「何をするか」だけ先に見る
次にサンプルとして、レシートや請求書のメモが雑多に入った実務フォルダを用意した(すべて検証用のダミーテキスト)。
invoice_yamada_0910.txt （請求書メモ）
receipt_starbucks_0912.txt（レシート）
meeting_notes_0911.txt （会議メモ）
receipt_seven_0913.txt （レシート）
random_photo_caption.txt （写真メモ）
コピペ用プロンプト②(前提条件: 整理したいフォルダでclaudeを起動していること):
claude --permission-mode plan
> このフォルダの中身を見て、内容ごとに分類したうえでサブフォルダに整理する計画を教えて。まだ実行はしないで、計画だけ教えて。
期待される結果: ファイルを移動せずに、分類案だけが文章で返ってくる。実際の応答:
/private/tmp/nonengineer-demoの5ファイルを内容別に4つのサブフォルダへ分類・移動します。
– 請求書/ → invoice_yamada_0910.txt
– レシート/ → receipt_seven_0913.txt, receipt_starbucks_0912.txt
– 会議メモ/ → meeting_notes_0911.txt
– プライベート/ → random_photo_caption.txt
この計画で問題なければ「実行して」と言ってください。
成功判定: lsでフォルダの中身を見て、ファイルが1つも動いていないことを確認する。plan modeは「調査はするが書き込まない」モードなので、ここで何かが移動していたら設定がおかしい。
つまずき所①: スクリプトから試すとplan modeの見た目が変わる
このブログの検証はスクリプト向けの非対話(-p)実行で行ったが、この場合Claude自身が「Neither のツール(ExitPlanMode / AskUserQuestion)もこの環境では見つからなかったため、テキストで計画をお伝えします」と述べて、通常の対話ターミナルで出るはずの「計画を承認しますか?」という選択式UIの代わりに、ただの文章で計画を返してきた。普段ターミナルでclaudeを直接起動して使う非エンジニアには影響しないが、「誰かのブログのコマンドをそのままコピペしたら、承認画面が出ずに素通りしたように見えた」という混乱はここから起きうる。対話ターミナルでは公式ドキュメント記載の通り承認の選択肢(「Yes, and use auto mode」等)が表示されるので、実行前に必ずその画面を確認してほしい。
ステップ2: acceptEditsモードで実際に実行する
計画に納得したら、今度は本当に実行するモードに切り替える。
コピペ用プロンプト③(前提条件: ステップ1の計画に納得していること):
claude --permission-mode acceptEdits
> このフォルダの中身を見て、内容ごとに分類してサブフォルダに整理して。ファイル名は変えないでください。
期待される結果と実測: 実際に実行すると18.9秒・実費0.15ドルで完了し、find . -maxdepth 2で確認したところ以下のようにフォルダが作られていた(ファイル名は指示通り変更なし)。
./レシート/receipt_seven_0913.txt
./レシート/receipt_starbucks_0912.txt
./会議メモ/meeting_notes_0911.txt
./個人メモ/random_photo_caption.txt
./請求書/invoice_yamada_0910.txt
成功判定: 元のフォルダ直下にファイルが残っておらず、内容に対応したサブフォルダの中に移動していれば成功。acceptEditsモードはファイル編集・移動は確認なしで進めるが、公式ドキュメントによれば作業フォルダの外や「保護されたパス」への書き込みは対象外で、その場合は通常通り確認が入る。
ステップ3: 出力スタイルで「説明の詳しさ」を変える
非エンジニアがつまずきやすいのは「何が起きたか分からないまま結果だけ返ってくる」ことだ。ExplanatoryスタイルはClaude Codeの意思決定を随所で説明してくれる。
コピペ用プロンプト④(前提条件: なし。設定変更のみで数秒):
/output-style Explanatory
期待される結果: .claude/settings.local.jsonに{"outputStyle": "Explanatory"}が書き込まれ、以後の応答に「なぜこの分類にしたか」といった説明が増える。実際に検証フォルダで実行し、設定ファイルの中身を確認したところ、期待通りの内容が書き込まれていた。
成功判定: プロジェクト直下の.claude/settings.local.jsonを開き、outputStyleの値が指定したスタイル名になっていれば成功。
つまずき所②: 公式ドキュメントの記載と実際の動作が食い違っていた
出力スタイルのドキュメントには次のように明記されている。
The standalone
/output-stylecommand was deprecated in v2.1.73 and removed in v2.1.91. Use/configor edit theoutputStylesetting directly.
(スタンドアロンの/output-styleコマンドはv2.1.73で非推奨化され、v2.1.91で削除された。/configを使うか、outputStyle設定を直接編集すること)
ところが手元のv2.1.270(v2.1.91よりはるかに新しいバージョン)で実際に/output-styleおよび/output-style Explanatoryを実行したところ、どちらも正常に動作し、一覧表示も設定の書き込みも/configと同じ.claude/settings.local.jsonに対して行われた。しかもこの呼び出しはtotal_cost_usd: 0のローカルコマンドとして即座に処理され、廃止されたコマンドが誤動作しているような形跡もなかった。
つまり「ドキュメントには削除済みと書いてあるが、実際には動く」という食い違いを実機で確認した形になる。これは以前の検証記事群で確認した「壊れ方」の分類でいう③(実は動く・素通り)に近いが、今回は新機能ではなく既存コマンドの廃止予告についての食い違いである点が異なる。GitHub Issue検索では今回の具体的な事象(/output-styleが削除予告後も動作し続ける点)に一致する報告は見つからなかった。読者が同じ挙動を試す場合は、ドキュメント上の正式な操作方法である/configを基本としつつ、手元のバージョンでの実際の挙動は自分で確認してほしい。
活用例:同じ型を他の実務に当てはめる
今回検証した「①plan modeで計画だけ見る→②acceptEditsで実行→③Explanatoryで説明を増やす」という型は、ファイル整理以外の非エンジニアの実務にもそのまま当てはめられる。たとえば次のような場面が考えられる(いずれも今回の実験で検証したファイル整理と同じ、読み書きとテキスト処理が中心のタスクという点は共通しているため、同様の安全な始め方が有効なはずだが、この記事で実際に動かして確認したのはファイル整理の1例のみである点は明記しておく)。
- 大量のテキストメモ・議事録を「誰の発言か」「決定事項か」で仕分けたいとき
- CSVで受け取ったデータを内容ごとに複数ファイルへ分割したいとき
- 同じ形式のファイル名を一括で分かりやすい名前に統一したいとき
いずれも「まずplan modeで計画を確認し、納得してから実行する」という順序を守れば、コードを書けなくても、何をされるか分からないまま実行してしまうリスクを避けられる。
つまずいたときの安全装置
途中で「思っていた動きと違う」と感じたら、Shift+Tabでいつでもdefault(Manual)モードに戻せる。Manualモードは読み取り以外のすべてで確認を挟むため、非エンジニアが安心して原点回帰できる状態になる。また、今回のような整理タスクはGitやバックアップのない実データで最初から試さず、まずは今回のようにコピーしたテスト用フォルダで挙動を確認してから本番のフォルダに使うことを勧める。
まとめ
| ステップ | コマンド | 費用 | 所要時間(実測) |
|---|---|---|---|
| 現状確認 | /output-style |
$0 | 数秒 |
| 計画だけ確認 | --permission-mode plan |
約0.28ドル | 48秒 |
| 実際に実行 | --permission-mode acceptEdits |
約0.15ドル | 19秒 |
| 説明を詳しくする | /output-style Explanatory |
$0 | 数秒 |
このブログ記事全体の検証にかかった実費は合計で約0.43ドル。コードを1行も書かず、「まず計画を見る→納得してから実行する→説明を詳しくする」という3手順だけで、非エンジニアでも自分のファイル整理のような実務タスクをClaude Codeに任せられることを確認できた。ただし、ドキュメントの記載が必ずしも手元のバージョンの実際の挙動と一致するとは限らない(今回の/output-styleのように)ため、重要な操作の前には「まずplan modeで計画だけ見る」を習慣にすることを勧める。
参考にした一次情報: Output styles、Choose a permission mode(いずれもcode.claude.com公式ドキュメント)。GitHub Issue検索はgh issue list --repo anthropics/claude-codeで実施したが、/output-style廃止後も動作する点に一致する既存報告は見つからなかった。
Comments