タグ: 学習記録

  • /init ー CLAUDE.md、3日かけて手書きしてた私の話

    /init ー CLAUDE.md、3日かけて手書きしてた私の話

    ずっと、白紙から書いてた

    CLAUDE.md(Claude が会話のたびに最初に読むメモ書きのようなファイル)を、私は3日かけて手書きしていた。プロジェクトの構成を眺め、命名規則を書き写し、テストの動かし方を思い出して並べて、最後に誤字を直して、また並べ替えた。エジプトのピラミッドを建てたファラオたちもこんな気持ちだったのかもしれない(まあ彼らの時代に重機などないのだが)。

    そして昨日、/init というスラッシュコマンドの存在を知った。

    「Claude が勝手にプロジェクトを読んで CLAUDE.md の下書きを作ってくれる」と公式ドキュメントには書いてある。3日。私の3日。返してほしい。


    結論マップ(ビフォー/アフター)

    場面/init を知る前/init を打ったあと
    CLAUDE.md の作り方手で1から書く(私は3日溶かした)1コマンドで下書きが出てくる
    プロジェクト把握自分でフォルダを眺めて思い出すClaude がスキャンして要点を抜く
    仕上げ「これ書き忘れてた…」を3日後に発見出てきた下書きを「足す・削る」だけ

    ピラミッドが3秒で建った気分。ただし完成形ではなく下書きである、という1点だけ最後に詳しく書く。


    /init って何をするコマンド

    公式ドキュメントによれば、/init は Claude Code の対話モード(ターミナルで claude と打って起動した状態)の中で打つスラッシュコマンド で、いま開いているプロジェクトを Claude が自分で歩き回って CLAUDE.md の下書きを生成してくれる機能だ。

    具体的には Claude が以下を自分で見に行く:

    • フォルダ構成(どこに何があるか)
    • package.json / pyproject.toml などの設定ファイル(使っているフレームワーク・依存ライブラリ)
    • 既存のドキュメント(README など)
    • ソースコードの命名規則・スタイル

    これらを材料に、「ビルド方法」「テスト方法」「主要ディレクトリの説明」「コーディング規約」などを箇条書きにした CLAUDE.md の下書き を1つ書き出してくれる。

    💡 「Claude が読みやすいように、Claude が自分の取扱説明書を自分で書く」と説明すると近い。私は最初これを聞いて「自分で履歴書書く AI、強い」と思った。


    実際に打つ手順(最小5ステップ)

    1. ターミナルで対象プロジェクトのフォルダに移動する(cd my-project のような移動コマンドを使う)
    2. claude と打って Claude Code を起動する
    3. 起動後のプロンプトに /init と入力して Enter
    4. Claude がプロジェクトを読んで下書きを生成する(数秒〜数十秒)
    5. 生成された CLAUDE.md を自分の目で読み、足りない部分・誤った部分を編集する

    ポイントは 5番。/init はあくまで下書きを置いてくれるだけで、完成版を作ってくれるわけではない。Claude 公式の解説記事にも「think of /init as a starting point, not a finished product(出発点であって完成品ではない)」とはっきり書かれている(公式 Best Practices にも同主旨の記述がある)。


    生成される CLAUDE.md のイメージ

    たとえば、私が書いている架空の家計簿アプリ(仮に kakebo-app という名前のNode.jsプロジェクト)で /init を打つと、こんな雰囲気の下書きが出てくる:

    # kakebo-app
    A personal finance tracker built with Node.js and Express.
    ## Build & Run
    - Install: `npm install`
    - Dev server: `npm run dev`
    - Production build: `npm run build`
    ## Test
    - Unit tests: `npm test`
    - E2E tests: `npm run test:e2e`
    ## Project Structure
    - `src/routes/`  ... API endpoints
    - `src/models/`  ... Database models (using Prisma)
    - `src/views/`   ... EJS templates
    - `tests/`       ... Jest test suites
    ## Conventions
    - Indent: 2 spaces
    - Quotes: single quotes for JS, double for JSON
    - File naming: kebab-case
    

    「あ、これでいい」と思うところと「いや、ここは違う」と思うところが混じった下書きになる。たとえば私の場合、Conventions 欄に「絶対 commit 前に lint を回す」を足したり、「src/views/ は EJS じゃなくて Pug を使ってる」を直したりする。プロの料理人がレシピ本のレシピを試食して「醤油を足したい」と言うのと同じ手つき。

    💡 上の例は架空のプロジェクトのもの。あなたのプロジェクトでは中身がぜんぜん違う形で出てくる。それで正しい。


    新しい /init(対話モード)も来ている

    公式ブログと Best Practices によると、2026年3月から 対話型の新しい /init が試験的に提供されている。CLAUDE_CODE_NEW_INIT=1 という環境変数(プログラムに渡す設定値のこと)を立てて Claude を起動すると、こちらに切り替わる。

    CLAUDE_CODE_NEW_INIT=1 claude
    

    何が違うか。従来版はファイルを勝手に読んで下書きを書く(ボトムアップ:素材から作る)。新版はファイルを読まず、AskUserQuestion(Claude が選択肢付きで質問してくる仕組み・以前の記事で取り上げた)を使って私に質問しながら作っていく(トップダウン:意図から作る)。

    💡 「私の作業のうち、よく繰り返している作業は?」「危ないからフックで止めたい操作は?」のような質問に答えていくと、CLAUDE.md だけでなくスキルや Hooks の雛形まで一緒に整えてくれる、というしくみ。インタビュー上手なフリーランスのコンサルが、私の机を見ずに私の話だけで業務マニュアルを書いてくれる、と思うと近い。

    なお新版はまだフラグ付きの実験的機能なので、通常の /init だけ覚えれば、明日からの作業は十分カバーできる。


    ここで止まりそうなポイント

    • 対話モードで打つ:/init はターミナルから claude --init のような呼び方では打てない。claude を起動して対話画面に入ってから、その中で /init と打つ。私は最初これを「シェルコマンド」と勘違いし、シェルに直接打って怒られた(家のリモコンを冷蔵庫に向けて押していた)
    • 既存の CLAUDE.md は上書きされる可能性:すでに CLAUDE.md がある状態で /init をもう一度回すと、内容が書き換わるか・差分が提示される(Claude のバージョンで挙動が変わる)。実行前に既存ファイルをバックアップすることをおすすめする。私は「これ、賢く merge してくれるはず…」と祈ったが、祈りで Git の履歴は残らない
    • 生成内容を信じすぎない:/init はファイルを「見た」結果で書くので、まだコードに書かれていないルール(たとえば「PR は必ず2人レビューする」のような運用ルール)は当然書かれない。出てきた下書きをスタート地点に、自分の頭で足す工程は必ず必要

    まとめ

    /init は CLAUDE.md の下書きを Claude 自身に書かせるスラッシュコマンド。手で1から書くより圧倒的に早く、しかも基本骨格は埋まった状態で出てくる。

    • まずは claude を起動 →/init を1回打つ
    • 出てきた下書きを読み、削り、足す(ここが本番)
    • 余裕が出てきたら CLAUDE_CODE_NEW_INIT=1 の対話版も試す

    私が次にやりたいのは、すでに育っている既存プロジェクトに /init をぶつけて、私が3日かけて書いた CLAUDE.md と Claude が30秒で書いた CLAUDE.md を並べて比較すること。たぶん私が負ける。負けても勉強になる、という意味で負けても勝ちという不思議な構図。

    なお本記事の挙動・コマンド名は 2026-04-28 時点の公式ドキュメントに基づく。Claude Code は更新が早いので、実行前に必ず一次情報を確認してほしい。


    関連リンク(一次情報)


  • ダウンロードとインストール ー 同じことだと思って混ぜて使ってた

    ダウンロードとインストール ー 同じことだと思って混ぜて使ってた


    結論マップ(ビフォー/アフター)

    項目ダウンロードインストール
    何をするファイルをPCにコピーして保存する保存したファイルを「使える状態」にする
    終わったあとフォルダに置かれているだけデスクトップやスタートメニューから起動できる
    例えるなら段ボールが家に届いた中身を出して棚に並べた

    ざっくり言うと

    ダウンロードは「ネットからPCにファイルを持ってくる」工程。スーパーで商品をカゴに入れて家まで持って帰るイメージだ。

    インストールは「持ってきたファイルを実際に使えるように設置する」工程。家具で言えば、組み立てて部屋に配置する作業に近い。届いたソファを玄関に置いたまま「届いた=座れる」と主張する人はいない。でもダウンロードに関しては、私たちは平気でそれをやる。

    ここで私がつまずいたのは、画像や音楽はダウンロードだけで使えるという事実だ。MP3を保存すればすぐ再生できる。でもソフトウェア(プログラム)は「保存しただけでは動かない」ので、別途インストールという工程が必要になる。段ボールが届いただけでは、中の猫が生きているか動いているかは確定しない——ソフトウェアも、ダウンロードしただけでは「使える」とは限らないのだ。

    ファイルの種類ダウンロードだけで使える?
    写真・音楽・動画使える(インストール不要)
    Word/Excel の文書使える(中身を読むだけなら)
    ソフトウェア(exe・dmg・sh)使えない(インストールが必要)

    一番シンプルな使い方

    ソフトウェアをPCに入れるときの、私が分解できた3ステップ:

    1. ダウンロード:公式サイトのボタンを押す。.exe(Windows)や .dmg(Mac)ファイルが、PC内のダウンロードフォルダに保存される。ここで「ダウンロード完了」と表示が出る。ちなみに私のダウンロードフォルダには、用途を忘れた .exe が3つくらい眠っている。みなさんもそうだと信じている。
    2. インストール開始:そのファイルをダブルクリックして開く。「次へ」「同意する」「インストール先を選ぶ」などの画面が出てくる。これがインストール作業の本体。「次へ」連打で結局何に同意したかは、聞かないでほしい。
    3. インストール完了:最後に「完了」ボタンを押すと、デスクトップやスタートメニューにアイコンが出る。この段階で初めて『使える』状態になる。

    スマホアプリだと、App Store や Google Play が裏で1〜3を一気にやってくれているので、私たちは「インストール」しか意識しなくて済んでいる。スマホは私たちを甘やかしてくれる。PCに来るとその優しさは消えるので、2工程が分かれて見えて混乱しやすい。


    コピペして使える例

    ここまで読んで眠くなった人、起きてください。ここからコードゾーンです。

    例えば、メモ帳の代わりに使える架空のテキストエディタ「NoteFlex」を入れるとする。

    # 1. ダウンロード(ネットから .exe を取得してダウンロードフォルダに保存)
    curl -O https://noteflex.example.com/installer/noteflex-1.0.exe
    # 2. インストール(ダウンロードした .exe を実行)
    .\noteflex-1.0.exe

    💡 ポイント: curl(カール)はネットからファイルを取ってくるコマンド。1行目はファイルを「持ってくる」だけ、2行目の .exe 実行で初めて「使える状態」になる。1行目だけだと NoteFlex は起動できない。

    ちなみに Claude Code を Windows に入れるときの公式コマンドは、この2工程を1行に詰めた書き方になっている。これは PowerShell(Windows標準のコマンド入力画面)に貼り付けて実行するコマンドだ。

    irm https://claude.ai/install.ps1 | iex

    irm、iex。初見の私の感想は「呪文ですか?」だった。落ち着いて分解すると、ちゃんと意味がある。

    💡 ポイント: irm がスクリプトを「ダウンロード」、iex がそれを「実行=インストール」する役割。パイプ | の左右で工程が分かれていると思って読むと、呪文が急に普通の手順書に見えてくる。


    引っかかりやすいポイント

    これ、私だけじゃないと信じたいのですが、こんな経験ありませんか。

    • 「ダウンロードしました」を「使える状態」と勘違いする: ファイルが保存フォルダにあるだけで、実行はまだ。デスクトップにアイコンが出ていなければ、インストールは終わっていない。
    • インストール画面を閉じて『終わったつもり』になる: ウィザード(「次へ」を連打する設定画面)の途中でキャンセルすると、ファイルだけ残って中途半端な状態になることがある。最後の「完了」を押し切るまでが1セット。
    • ZIPを解凍しただけで満足する: ZIP を展開してフォルダができると「終わった感」が出る。あの達成感、わかる。でも中身の setup.exe を実行していなければ、まだダウンロード相当。解凍 ≠ インストール。

    3行でまとめると

    • ダウンロード = 持ってくる:ネット上のファイルをPCにコピーする工程。
    • インストール = 使える状態にする:ダウンロードしたファイルを設置・登録して、起動できる形に整える工程。
    • スマホはこの2工程を裏で1つにまとめてくれている:だからPCに来ると2つに分かれて見えて混乱する。

    過去の自分に教えてあげたい。ダウンロードとインストールは別の駅です、乗り換えてください、と。


    関連リンク

  • ZIP「解凍」と「展開」事件 ー 私と部長と新人の三国志

    ZIP「解凍」と「展開」事件 ー 私と部長と新人の三国志

    第一幕:事件は会議室で起きた

    ある月曜の朝、部長が私の机にやってきてこう言った。

    「セルシーさん、このZIPファイル、解凍しといて」

    「了解です」と返してファイルを受け取った私は、タスクが多すぎたので新人くんに丸投げしようと思い、こう言った。

    「これ、展開しといて」

    新人くんがキーボードに置きかけた手を止めて、まばたきを2回した。

    「……展開、ですか?」
    「うん、展開」
    「あの、3Dモデルでも作るんですか?」

    会議室の空気が、止まった。


    結論マップ(先に答え)

    用語意味結果
    解凍ZIPファイルを開いて中身を取り出す同じ
    展開ZIPファイルを開いて中身を取り出す同じ

    同じです。 結論はこれです。ここで記事を閉じてもらっても構わないのですが、読み終わった人が会社で「同じだから」と部長に言うとケンカになるので、もう少しだけ事件を追ってください。


    第二幕:部長と新人の世代戦争

    私は事情を整理した。整理した結果、こうなった。

    派閥平均年齢主な使用環境口癖
    解凍派40代後半〜Lhaplus、+Lhaca、LZH時代の生き残り「解凍しといて」
    展開派20代〜30代前半Windows 11標準の右クリック「すべて展開」

    部長は、解凍派の総大将である。新人くんは展開派の前線部隊である。私はその中間に位置する国境警備兵として、両軍の砲火を受けながら毎日ZIPファイルを開いている。

    ちなみに新人くんが「3Dモデルでも作るんですか?」と返してきた理由はあとで聞いた。彼の世代にとって「展開」とは、Blender(3Dソフト)でUV展開図を作る作業のことらしい。ZIPファイルから立方体の展開図を想像する世代が、すでに存在していたのである。


    第三幕:私、ルーツを探しに行く

    両派閥の停戦のため、私はネットの森に分け入った。「なぜZIPの操作にお寿司の冷凍庫みたいな言葉が使われているのか」を解明するためである。

    辿り着いたのは、ある日本のお医者さんの存在だった。

    吉崎栄泰さん。1955年、北海道生まれ。内科医をしながら、1988年に「LHarc」という圧縮ソフトを作った人である。これがのちに「LHA(ファイル拡張子は .lzh)」と呼ばれ、日本中のフロッピーディスクをパンパンに膨らませることになる。

    このソフトの画面に、当時こんなメッセージが表示されていた。

    Freezing  : data1.txt
    Melting   : data1.txt
    

    Freezing(凍結) と Melting(融解)。圧縮するときは凍らせて、戻すときは溶かす。

    💡 ポイント: ファイルを「凍らせる」「溶かす」というメタファーは、日本のパソコン通信ユーザーの間でじわじわと定着した。Meltingが日本語に乗り移った結果、生まれた言葉が——解凍。

    つまり日本のZIPユーザーは、30年以上前からファイルを電子レンジで温めるような気分でPCを使っていたわけだ。私はこれを知った瞬間、コンビニのファミチキを温めるあの気持ちと、ZIPを開く気持ちが一直線につながった。胃袋とPCの間に橋がかかった。


    第四幕:Windowsが「展開」と言い出した日

    時は流れ、Windowsはバージョンを重ねた。気づけばエクスプローラーの右クリックメニューには「すべて展開」と書かれていた。Microsoftが勝手に和訳の路線を変更したのである。

    英語の「Extract(取り出す・抽出する)」を直訳した結果が「展開」だ。一方「解凍」は、英語に対応する単語がない、日本人の冷蔵庫的発想から生まれたオリジナル翻訳である。

    用語由来翻訳の方向性
    解凍日本のLHA文化 → Melting → 解凍意訳・詩的
    展開Microsoftの公式UI → Extract → 展開直訳・実務的

    つまり部長は詩を、新人くんは仕様書を読んでいるのだ。会議室で噛み合うわけがない。


    第五幕:実験してみた

    伝聞だけで終わるのもアレなので、私はZIPファイルに向かって声を出してみた。

    私: 「あなたを解凍します」
    ZIP: (中身が出てくる)
    私: 「あなたを展開します」
    ZIP: (中身が出てくる)
    私: 「あなたを溶かします」
    ZIP: (中身が出てくる)
    私: 「あなたを開示します」
    ZIP: (中身が出てくる)
    

    ZIPは何を言っても開く。 言葉を選ぶのは人間の都合であって、ZIP本人は気にしていない。これは大きな発見だった。

    ちなみに、コマンドラインで操作するなら、Windowsではこう打つ。

    # ZIPファイルを開く(呼び方は心の中で自由)
    Expand-Archive -Path .\sample.zip -DestinationPath .\output
    

    💡 ポイント: Expand-Archive はPowerShellの標準コマンドで、ZIPの中身を指定フォルダに取り出す。コマンド名の動詞は Expand(展開する)。Microsoftはここでも「展開」で揃えている。一方で、Mac勢は unzip sample.zip と打つ。Macは「ジップを脱ぐ」派である。


    エピローグ:会議室に戻る

    私は部長と新人くんに、調査結果をこう伝えた。

    「解凍と展開は同じです。ただし、解凍は北海道生まれの詩、展開はMicrosoft発の翻訳です」

    部長は「ふーん、ロマンがあるな」と言った。新人くんは「3Dじゃなくてよかった」と言った。私のZIPファイルは、その間ずっと机の上で待機していた。

    職場で世代の違うメンバーとZIPの話をするときは、こう言うのが一番穏便だと学んだ。

    「そのファイル、開いといて。」

    圧縮を解く動作を、開くという日本語が全部包み込んでくれる。 言葉の包み紙としての「開く」は偉大である。


    まとめ:今日の学び

    • 「解凍」と「展開」はZIPに対しては同じ意味。中身が出てくる結果はまったく一緒
    • 「解凍」は日本独自のロマン用語(LHAのMeltingメッセージが起源)
    • 「展開」はWindows公式の翻訳路線で、若い世代の標準語になりつつある
    • 世代をまたぐ会議では「開いといて」がすべてを丸く収める
  • チェックポイント ー Esc 2回で昨日の失敗が消える、Ctrl+Z よりずっと強い

    チェックポイント ー Esc 2回で昨日の失敗が消える、Ctrl+Z よりずっと強い

    あれ、これだったのか

    Claude にファイルをごっそり書き換えてもらったあと、「やっぱり前のほうがよかったかも……」と後悔したことがある。でもスクロールして戻っても、上書きされたファイルは戻ってこない。Ctrl+Z を連打してみたけど、消えていったのはたぶん私の昨日の努力だけだった。

    Claude Code(Anthropic が提供するターミナル向けの AI コーディングツール)には、すべての編集前に自動でスナップショットを撮ってくれる「チェックポイント」という機能が最初から入っている。知らなかった私は、昨日までずっと Git(ファイルのバージョンを管理するツール)を手で叩いて保険をかけていた。保険屋の窓口が隣にあったのに、自分で契約書を書いていた気分。


    これ1行で何が変わるか

    チェックポイントは、Claude Code があなたのファイルを編集する直前に、その状態を自動で記録してくれる機能だ。記録は会話ごとではなく「プロンプトを送るたびに」作られるので、巻き戻したい地点を1つ1つ選べる。

    ちなみに「プロンプト」とはあなたが Claude に送るお願いの文章のこと。1プロンプト = 1チェックポイント。ボス戦前に「ここでセーブ」とやる RPG と同じ感覚で、ファイル編集以外(Bash コマンドでのファイル削除・移動など)は対象外だが、Claude が Write / Edit / NotebookEdit ツールで触ったファイルはすべて拾ってくれる。

    記録は自動で最大30日保存され、セッション(1回の会話)を閉じても残る。だから昨日のミスも今日取り返せる。映画『メメント』の主人公は記憶が続かずメモに頼っていたが、こっちは逆で、私が忘れても Claude が覚えていてくれる。


    一番シンプルな使い方

    1. Claude Code 上で何かを編集してもらう(複数ファイル書き換えでもOK)
    2. Esc キーを2回連続で押す。または /rewind とタイプする
    3. 画面に「過去のプロンプト一覧」が出てくるので、戻したい地点を矢印キーで選ぶ
    4. 戻し方を選ぶ(コードだけ / 会話だけ / 両方 / まとめて圧縮)
    5. Enter を押すと、その地点までファイルと会話が瞬時に戻る

    ポイントは、コードと会話を別々に戻せるところ。会話の流れは残したままコードだけロールバックしたり、逆にコードは保ったまま会話だけリセットしたりできる。前者は「やり直したいけど Claude に経緯は覚えていてほしい」とき、後者は「コードは気に入ったけど話が脱線したので会話だけ整理したい」ときに便利だ。


    こう書いたら動いた

    架空のレシピアプリで、うっかり大規模リファクタを Claude に頼んでしまった場面を想像してほしい。こんなやり取りになる。

    > src/recipes/ 以下を全部 TypeScript に書き換えて
    (Claude が 12ファイルを一気に書き換える)
    > ……やっぱり元に戻したい
    (Esc を2回押す)
    ┌─ Rewind ────────────────────────────────┐
    │ › 3 prompts ago: "src/recipes/ 以下を…" │
    │ 2 prompts ago: "型エラーを直して" │
    │ 1 prompt ago: "テストも直して" │
    └─────────────────────────────────────────┘
    (上の "3 prompts ago" を選んで Enter)
    ┌─ Restore options ───────────────────────┐
    │ › Restore code and conversation │
    │ Restore conversation │
    │ Restore code │
    │ Summarize from here │
    │ Never mind │
    └─────────────────────────────────────────┘
    (Restore code and conversation を選ぶと、12ファイルが書き換え前に戻る)

    💡 ポイント: 「Summarize from here」を選ぶと、選んだ地点以降の会話が1段落の要約に圧縮される。/compact(会話全体を圧縮するコマンド)の「途中から版」で、前半の大事なやり取りは残したまま、後半のデバッグで膨らんだ部分だけ軽くできる。


    ここで止まった

    • Bash で動かしたファイルは戻らない: rm old.txt や mv a.txt b.txt を Claude がシェル経由でやると、チェックポイントの対象外になる。これを知らずに「巻き戻せば消したファイルも復活するはず」と思っていたら、戻らなかった。削除系は Git か OS のごみ箱が頼り。
    • 他のセッションやエディタからの変更は拾わない: 同じプロジェクトを VS Code で並行編集していたら、そっちの変更はチェックポイントに含まれない。Claude のチェックポイントは「このセッションの中で Claude が触ったファイル」専用と覚えておく。
    • Git の代わりにはならない: チェックポイントは30日で自動削除される。長期のバージョン管理や他人との共有は、引き続き Git(git commit でスナップショットを残すツール)の仕事。チェックポイントは「セッション内の Undo」、Git は「永久保存の歴史」と役割を分けて考える。

    3行でまとめると

    Claude Code のチェックポイントは、Esc 2回または /rewind でプロンプト単位の巻き戻しができる保険機能だ。コードだけ・会話だけ・両方・要約圧縮の4パターンから選べて、30日保存される。Bash 経由の削除や外部エディタの変更は拾わないので、Git との二段構えが安心。

    この機能を知る前の私は、Claude に大きな変更を頼むのが怖くて、毎回 git commit してから依頼していた。今は堂々と「全部書き換えて」と言える。戻せるという安心感は、触る勇気そのものだった。あの夜、泣きながら連打した Ctrl+Z を返してほしい気もするけど、Esc キー、2回でいいってよ。


    関連リンク

  • AskUserQuestion ー Claudeが逆に私に質問してきた

    AskUserQuestion ー Claudeが逆に私に質問してきた

    あれ、これだったのか

    Claudeに何かお願いしようとしたとき、ふと返ってきたのが「質問の答え」じゃなくて「質問」だった。

    え、逆になってる。

    でも冷静に考えると、当たり前の話で。職場でも「これお願いします」と言われた側の人間は「えっと、どういう形式で?」「いつまでに?」って確認しますよね。……確認しないで進めて「こうじゃなかった」ってなること、ありますよね。私はあります(しかも結構な頻度で)。

    それをClaudeがやってくれているだけ。問い返してきた = ちゃんと考えてる、ということでした。Cowork(※ClaudeのデスクトップAI作業支援ツール)に AskUserQuestion(選択肢UI) という機能があって、これがその確認の仕組みです。


    結論マップ(ビフォー/アフター)

    改善前(Before)改善後(After)
    曖昧な依頼でも問答無用で進めてしまう実行前に選択肢UIで確認する
    意図とズレた成果物が出来上がるユーザーの意図を正確に把握してから動く
    「こうじゃなかった」と後から修正最初に合わせることで手戻りがなくなる

    要するに何ができるか

    AskUserQuestion(アスクユーザークエスチョン)は、Cowork モードで Claudeが作業の前に「確認したいことを選択肢付きで聞いてくる」 機能です。

    ふだん私たちがClaudeに質問するのとは逆——Claudeが私に質問してきます。しかもボタン形式の選択肢で。テキストで長々と説明するより、ボタンをクリックするだけで意図が伝わるので、体感すごく楽です。「説明するのがめんどくさい」って思う場面ほど助かる。

    たとえば「先月の出費をまとめて」と頼んだとします。確認なしで突っ走られると、「カテゴリが違う」「単位が違う」「これじゃなかった……」という状況が普通に起きます。AskUserQuestionが入ると、Claudeは先に「どんな形式にしますか?」「カテゴリはどう分けますか?」を選択肢で出してくれます。

    ソクラテスが弟子に答えを教えるのではなく問いを投げかけて自分で考えさせた、あの問答法にちょっと似ていますが、Claudeの場合は「あなたの意図を正確に受け取りたい」という実用的な理由なので、哲学の授業は始まりません。安心してください。


    とりあえずやってみる

    特別な設定は不要です。Coworkモードで以下のような依頼を投げると、自然に体験できます。

    1. Coworkを起動して、複数の工程が絡む依頼を送る(例:「Excelファイルを整理して報告書にまとめて」)
    2. Claudeが即座に動き始めるのではなく、選択肢のパネルが表示される——「え、動いてない?」となる瞬間ですが、動いてないんじゃなく聞いてます
    3. 選択肢のボタンをクリックするか、補足テキストを入力する(難しいことはなにもない)
    4. Claudeが意図を把握してから本作業を開始する——ここからが本番

    「複数ステップある依頼」「ファイルが複数ある依頼」「形式の選択肢がある依頼」は特に確認が入りやすいです。単純な質問や一問一答の会話では出てきません。なので、いきなり使おうとしても来ないこともある。「なんか来ない」は普通です。


    実際に打ったプロンプト

    以下の2つのファイルを見て、先月の支出を
    「食費」「光熱費」「その他」に分類してまとめてください。
    添付: shopping_april.txt / bills_april.txt

    💡 ポイント: 「分類」「まとめ」「形式」が絡む依頼ほど確認が入りやすい。実は曖昧な依頼の方がAskUserQuestionが活躍する。依頼が雑なほど助かる、という逆説的な機能。

    Claudeが返してきた選択肢の例(こんなイメージです):

    どの形式でまとめますか?
    [A] 表形式(カテゴリ別)
    [B] 箇条書きリスト
    [C] 合計金額だけ出す

    Aを選ぶとそのまま表形式で出力が始まります。「えっそれだけでいいの」という使い勝手のよさ。この「えっそれだけ」感、最初体験したときけっこう感動しました。


    やらかしたこと


    • 「止まってる!」と焦って同じ指示を再送した: AskUserQuestionが表示されたとき「なんで反応がないんだろう」と思い、同じ依頼をもう一度送ってしまいました。Claudeは答えを待っていただけ。二重投稿になって少し混乱させてしまいました(ごめんなさい)。まず選択肢UIを確認するのが正解です。



    • 「なんでもいいよ」で返した: 「お任せして」と返したらClaudeは「お任せ」の中でそれなりの判断をしてくれました。出来上がったものはそれなりで、「あ、でもこっちがよかった」とは思いました。後悔はない。でも選択肢があるときはちゃんと選んだ方がいいです(当たり前のことを学んだ)。



    • 質問への返答より先に別の話をした: 「あ、でもそのファイルなんですけど、もう一個あって——」みたいな感じで別の補足を先に送ってしまい、会話がちょっとこんがらがりました。まずClaudeの質問に答えてから補足する順番が大事でした。割り込みはよくない(どこでも)。



    で、結局どうなの

    正直に言うと、最初は「いちいち確認しなくていいのに」と思っていました。早く始めてほしい、という気持ち。

    でも何度か「完成したけど形式が違う……」をやらかしてから、気持ちが変わりました。確認される一瞬を惜しんで、あとで1時間かけて修正する方がよっぽど時間の無駄です。1時間、返ってきません。

    AskUserQuestionは「Claudeが仕事をさぼっている」のではなく「正確にやろうとしている」から出てくる確認です。最初に意図を合わせるほど、最後に「こうじゃなかった」がなくなる。

    こういうことは最初から教えてほしかった。でも自分で気づく方が記憶に残るので、まあ、よかったです(そういうことにしておく)。


    関連リンク

  • CLAUDE.md ー 毎回同じ口頭説明、ついに卒業した

    CLAUDE.md ー 毎回同じ口頭説明、ついに卒業した

    あれ、これだったのか

    「口調はやわらかめで」「コードは書かないで」「日本語で返事して」。
    私はこの3行を、3日連続でClaudeに口頭でお願いしていた。
    3日目に思い出した。「これ、ファイルに書いておけるやつなんじゃ?」

    そのファイルが CLAUDE.md だった。


    結論マップ(ビフォー/アフター)

    改善前(Before)改善後(After)
    毎回チャットの冒頭に「日本語で・優しく・コードは省いて」と打ち込むプロジェクトを開いた瞬間、Claudeが既にそのルールで動いている
    Claudeが急に英語で返事してきて「あれ?」となる口調も言語もブレない。プロジェクト全体で一貫する
    「言ったよね?」と何度もリマインドする手間1回書いて保存。そのあとは存在を忘れていい

    これが本体

    CLAUDE.md(クロード・ドット・エムディー)は、Claudeに毎回読ませたい指示を書いておくテキストファイルだ。
    拡張子の .md は「マークダウン」。名前だけ強そうだが、要は見出しが書けるだけのただのメモ。メモ帳でもVS Codeでも開ける。身構えなくていい。

    公式ドキュメントの言い方を借りるなら、毎セッション開始時に自動で読まれる、Claude宛の置き手紙。
    枕草子なら「春はあけぼの」のあたりに「敬語多め」って書いておくイメージだ(清少納言、ごめん)。
    口頭で毎回お願いしていたことをファイルに書き写すだけで、Claudeはそれを前提にして話し始めてくれる。

    しかも置き場所が用途で使い分けられる。

    • ~/.claude/CLAUDE.md … 全プロジェクト共通の自分ルール(要は私の取扱説明書)。口調・言語・禁止事項などをここに書く
    • プロジェクト直下の CLAUDE.md … そのプロジェクトだけのルール(このフォルダ独自の方言)。チームで共有もできる
    • @path/to/file 構文での import … 別ファイルを CLAUDE.md から読み込む書き方。長くなりがちなルールを別ファイルに分割できる(昔は CLAUDE.local.md というローカル専用ファイルもあったが、現在は import 構文が推奨されている)

    これらは作業フォルダから上の階層に向かって順に読み込まれて、まとめてClaudeに渡される。「全体ルール+プロジェクト固有ルール」をきれいに分けて書ける。


    とりあえずやってみる

    迷いどころを全部スキップした最小手順がこれ。

    1. プロジェクトの一番上のフォルダ(自分が作業しているフォルダ)を開く
    2. その中に CLAUDE.md という名前の空ファイルを作る(メモ帳で「名前を付けて保存」でOK)
    3. 「Claudeに毎回伝えていたこと」を3〜5行書く(ここで完璧主義が顔を出すが無視。ファイル名すら最初に間違えた私が言うんだから間違いない)
    4. 保存して、Claude Codeを開き直す(または新しいセッションを始める)
    5. Claudeに「今回のルールわかってる?」と聞いて、書いた内容を返してくれたら成功

    ポイントは 「毎回伝えてた1行」を1つだけでいい こと。完璧を目指して長文を書こうとすると、たいてい書き終わる前に挫折する。私は最初の1行を書くだけで5分粘った。原稿用紙を前にした夏休み最終日の小学生だった。


    動いた設定をそのまま

    私が試しに作った、架空の「旅レシピ管理」プロジェクト用の CLAUDE.md がこれ。中身は本物のテキストとしてそのまま動く。

    # 旅レシピ管理プロジェクト
    このフォルダは、旅行先で食べた料理を再現するためのレシピメモ集です。
    ## 私の好み
    - 返答は日本語で。専門用語が出たら必ず1行で意味を補足してください
    - 文字数は1メモあたり300字以内におさめる
    - 材料の分量は2人分を基準にする
    ## ファイルの場所
    - 完成したレシピは `recipes/` フォルダに `国名_料理名.md` で保存
    - 試作中のメモは `drafts/` フォルダに置く(公開前なので触らないで)
    ## やらないでほしいこと
    - レシピの手順を勝手に省略しないでください
    - 「お好みで」など曖昧な表現は使わず、数値で書いてください
    

    💡 ポイント: 見出し(##)で「好み」「ファイルの場所」「やらないでほしいこと」を分けると、Claudeが「該当箇所だけ」を意識して動いてくれる。長く書くより、見出しでの分類のほうが効く。


    最初で詰まった4つ

    1. 置き場所を間違えた … デスクトップに置いて「読まれない!」と騒いでいた。CLAUDE.md は 作業しているプロジェクトフォルダの直下 に置かないと反応しない。場所を変えただけで治った。
    2. 長すぎて自分が読めなくなった … 良いことを書こうとして30行を超え、自分でも何を書いたか覚えてなかった。ファイル全体が毎セッションで読まれる仕組みなので、長くなりすぎたら別ファイルに分割するのが安全。公式の Best Practices にも「短く・人間が読める長さに保つ」と書かれている。
    3. 「禁止事項」だけ並べた … 「〜しないで」ばかりだと、Claudeはやってもいいことの判断に迷う。「これはやって・これはやらないで」をペアで書く と動きが安定する。「コードを書かないで」より「コードは書かず、手順だけ箇条書きにしてください」のほうが伝わる。
    4. ファイル名に小文字が混入 … 最初は Claude.md という名前で作ってしまい、「読まれない、なぜ?」と30分溶かした。正しくは すべて大文字の CLAUDE.md(拡張子の .md だけ小文字)。Mac・Linux など大文字小文字を区別する環境では、一文字でもケースが違うと完全に別ファイル扱いで無視される。リネームしただけで動いた。

    使ってみての正直な感想

    CLAUDE.md を作る前と後で、Claudeとの会話の冒頭5分が完全に消えた。
    「いつもの前提を伝える時間」が0になっただけで、いきなり本題に入れる。

    書くのに迷ったら、「直近3回、Claudeに同じ注意をしたこと」をそのまま書き写す のがいちばん早い。
    それは「私が毎回伝えたいルール」の動かぬ証拠だから。

    3回同じことを言ったら、ファイルに書く。3歳児に同じ質問をされ続けた育児ベテランの先輩が言ってたやつだ。
    Claudeも、3歳児だったらしい。


    関連リンク

  • スケジュール×フォルダ移動のトラブル体験記 ー 掃除したつもりが全部止まった日

    スケジュール×フォルダ移動のトラブル体験記 ー 掃除したつもりが全部止まった日

    整理整頓、こわい

    結論から言います。整理しようとして全部止まりました。

    Cowork(※ClaudeのデスクトップAI作業支援ツール)の作業フォルダがいつの間にか2つになっていて、「1つにまとめよう」と軽い気持ちで手を出したら、スケジュールタスクが5件まとめて「タスクファイルが見つからないか、形式が正しくありません」になり、さらにタスクを編集しようとすると「パストラバーサル検知」で全弾かれ。

    部屋を掃除していたら掃除機の電源が消え、洗濯機まで止まり、なぜか玄関の鍵まで閉まる、みたいな連鎖でした。今日はその一部始終を、恥を忍んで書きます。


    発端:なんで「Claude」と「Claude_blog」、2つあるんだ?

    Coworkにはマウント(※選択フォルダ)という概念があって、「space」と呼ばれる作業単位の中に、作業対象フォルダを登録できます。私は「Claude_blog」というspaceを使っていたのですが、ある日spaceの設定を覗いたらフォルダが2つ登録されていました。

    • C:\Users\〇〇\Documents\Claude ←昔のなごり
    • C:\Users\〇〇\Documents\Claude_blog ←今のメイン

    同じような名前のフォルダがspaceに同居している状態で、作業ファイルが微妙にどっちにあるかバラバラ。どっちで編集しても動くけど、どっちにあるか分からない。 これは気持ち悪い。というわけで「Claude」の方を登録解除することにしました。

    ちなみにCoworkのUIからはマウントの個別解除ができない場面があって(私のバージョンではそう見えた)、設定ファイルを直接編集する方法を取りました。


    spaces.json を直接いじる

    Coworkのマウント設定は、以下のJSONファイルに保存されています。

    %APPDATA%\Claude\local-agent-mode-sessions\{セッションUUID}\{エージェントUUID}\spaces.json
    
    
    

    中身はこんな感じ(抜粋)です。

    {
      "spaces": [
        {
          "id": "space-xxxx",
          "name": "Claude_blog",
          "folders": [
            { "path": "C:\\Users\\〇〇\\Documents\\Claude" },
            { "path": "C:\\Users\\〇〇\\Documents\\Claude_blog" }
          ]
        }
      ]
    }
    

    folders 配列から不要な方(Claude)のエントリを削除して保存。Coworkを完全終了して再起動。ここまでは想定通り、マウントが1つに統一されて「よし、すっきりした」と思いました。

    この時点ではまだ平和だったんです。嫌な予感がするときほど、なんにも起きていない。


    副作用その1:スケジュールの「手順」ボタンがいっせいに死ぬ

    Coworkの左サイドバーには「Scheduled(スケジュール)」という項目があって、登録済みの定期タスクが一覧表示されます。タスクごとに「手順」というボタンがあり、押すとタスクの中身(SKILL.md)が見られる仕組みです。

    マウント整理後、なにげに「手順」を押したら。

    タスクファイルが見つからないか、形式が正しくありません。
    
    
    

    5件全部これ。全滅です。

    原因はわりと単純で、scheduled-tasks.json(spaces.jsonと同じフォルダにある)に登録されている各タスクの filePath が、もう存在しない旧パス(Claude\Scheduled\...)を指していました。親フォルダの参照を切ったせいで、スケジューラ側からタスク本体が見えなくなったわけです。

    応急処置

    scheduled-tasks.json を直接開いて、5件の filePath を現行パス(Claude_blog\Scheduled\...)に書き換え。保存するとUIはすぐ復旧しました。

    ここまでで「まあ、こういうこともあるよね」くらいの認識でした。この油断がこの後の首を絞めます。


    副作用その2:update_scheduled_task が全滅

    翌日、タスクの説明文を微調整しようとしたら、全部が以下で弾かれました。

    Failed to update scheduled task: Invalid file path: path traversal detected
    
    
    

    パストラバーサル(※本来アクセスしてはいけない場所にパスで抜けようとする攻撃手法の呼び方)。え、私、攻撃してます?してないです。説明文を直したいだけです。

    不思議なのは、全部が全部ダメなわけではない点でした。

    操作結果
    enabled のトグル(有効/無効切替)✅ 通る
    新規タスクの作成✅ 通る
    一覧取得✅ 通る
    description / prompt の更新❌ パストラバーサル検知で拒否

    「一覧では見えるのに、書き換えようとすると見つからないと言われる」。幽霊タスクみたいな状態で、ちょっと怖かった。


    切り分け:幽霊の正体を探る

    こういうときは、変数を1つずつ固定して違いを見る のが鉄則らしいので(料理の味見と同じ理屈)、4ステップで切り分けました。

    1. enabled トグルだけ叩く → 成功(内部でSKILL.mdの書き込みが起きない操作)
    2. description だけ更新 → 失敗(内部でSKILL.mdの書き込みが起きる)
    3. 新しい場所(Documents\Claude\Scheduled\)にダミータスクを作る → 成功
    4. そのダミーに対して description を更新 → 成功

    結論:スケジューラが「ここに書くはず」と思っている場所(Documents\Claude\Scheduled\)と、実際にタスク本体がある場所(Documents\Claude_blog\Scheduled\)がズレていた。

    一覧取得は両方を横断して見てくれるのでタスクは普通に表示される。ところが更新時にSKILL.mdを書き換えようとすると、「本来の保存先の外にあるファイルパス」として検知され、パストラバーサル扱いで拒否される。幽霊の正体は、引っ越しした本人の住民票が古い住所のままだった、みたいな話です。


    そもそもスケジュールタスクのデフォルト保存先はどこ?

    ここで一度立ち止まって、「正しい保存先」ってそもそもどこなの?を調べました。

    結論を先に言うと、Windowsでのスケジュールタスクの既定の保存先は C:\Users\〇〇\Documents\Claude\Scheduled\{taskId}\SKILL.md です。これは create_scheduled_task(スケジュールタスク作成ツール)の仕様説明にはっきり書いてあります。

    The task will be stored as a skill file ({taskId}/SKILL.md) in C:\Users\〇〇\Documents\Claude\Scheduled/

    和訳すると「タスクは C:\Users\〇〇\Documents\Claude\Scheduled\ 配下に {taskId}/SKILL.md という形のスキルファイルとして保存されます」。ついでにCowork全体で見ると、プロジェクト本体も既定では Documents\Claude\ の下に作られるようになっています(こちらは公式ヘルプで確認)。つまり Documents\Claude は Cowork 全体のホームディレクトリ的な位置づけで、スケジュールタスクもその中に自分の部屋を持っている、と。

    じゃあ、なんで私のタスクは別フォルダ(Claude_blog\Scheduled\)にいたのか?経緯はシンプルで、最初に Documents\Claude\ を自分で作って一通りの作業をそこに集めていたのですが、後からブログ専用に Documents\Claude_blog\ を新規作成し、Claude\ の中身をまるっと Claude_blog\ に引っ越したんです。Scheduled\ フォルダもこのときに一緒に運ばれて、結果としてタスク本体が Claude_blog\Scheduled\ に居座ることになりました。既定の家に戻してあげれば、ツールがちゃんと認識してくれる — というのが今回の話のゴールでした。

    ちなみにここで地味に効いていたのが、そもそも私が手動で Claude というフォルダを先に作っていた という事実です。Claude(スケジューラ)が既定で使おうとしている Documents\Claude\ と、私が自分の意思で命名した Documents\Claude\。相談した覚えはないのに、フォルダ名がきっちり一致している。偶然、お互いに同じ名前を選んでいた——いわゆる両想いです(誰も嬉しくない両想い)。このネーミングの被りのおかげで、引っ越しの後も「両方Claudeの家に見える」状態が続き、どっちが本当の家か曖昧なまま共存できていた、とも言えます。

    • 既定: Documents\Claude\Scheduled\{taskId}\SKILL.md ← スケジューラが信じている住所
    • 迷子: Documents\Claude_blog\Scheduled\{taskId}\SKILL.md ← 昔の住所のまま止まっていた

    対処法(2つ)

    応急措置:直接ファイルを書き換える

    スケジューラは実行時にSKILL.mdをそのまま読むので、ファイルを直接編集すれば内容は反映される。つまり update_scheduled_task が使えなくても、エクスプローラからSKILL.mdを開いて中身を書き換えれば、次回実行時の挙動は変わります。description(先頭のフロントマター)も同じファイル内なのでこれで足ります。

    その日の仕事を止めないための一時しのぎ。病院で言う応急処置で、根治ではない。

    恒久対策:フォルダごと引っ越す

    本質的な解決は、実体を canonical な場所に戻すこと。つまり、

    移動元: C:\Users\〇〇\Documents\Claude_blog\Scheduled\{taskId}\
    移動先: C:\Users\〇〇\Documents\Claude\Scheduled\{taskId}\
    
    
    

    の引っ越しを手でやります。Windowsエクスプローラで、該当タスクのフォルダごと({taskId} ディレクトリ単位で)切り取り→貼り付け。{taskId} というディレクトリ名そのものが識別子なので、enabled や lastRunAt のような状態は引き継がれます。

    なお、これは ユーザー自身の手作業で行う必要があります。理由は単純で、Coworkのサンドボックス側から Documents\Claude\ 配下に新規で書き込む権限がないからです。「自分で動かすしかない」系のトラブルは、珍しい。


    試すなら(架空のタスクで再現する)

    本番タスクでいきなり壊さないよう、ダミーのスケジュールタスクで練習するのがおすすめです。

    /schedule
    
    
    

    とチャットに打つと、スケジュールタスク作成用のスキルが起動します。中身は何でもOK。たとえばこんな感じ。

    名前: folder-move-test
    スケジュール: Manual only(手動実行のみ)
    プロンプト: 「テスト用の無害なタスクです。実行されても何も起きません。」
    
    
    

    作ったタスクのフォルダを別の場所にエクスプローラで動かしてみて、
    一覧に出るか/「手順」ボタンで中身が見えるか/update が通るか、
    この3つを順に確認すると、今回のトラブルを1/10スケールで追体験できます。

    💡 ポイント: 「動くけど書き換えられない」は、一覧用と書き込み用でパスの見え方が違うときに起きがち。UIが便利に見せてくれている裏側を、たまに覗いておくと安心です。


    つまずきポイント

    • 整理整頓を軽く見ていた:フォルダを1つ外すだけ=安全、ではなかった。マウント整理は、参照している別の仕組み(スケジューラ)を巻き込むことを忘れていました。次にやるときは、影響範囲を一度書き出してから手を出します。
    • 一覧に出るから大丈夫、と思い込んだ:タスクが一覧に見えているのと、正しく動くのは別問題でした。「一覧表示 = 正常稼働」ではない。書き込みが絡む操作で初めて壊れるタイプのズレは、普段の使い方では気づけない。
    • エラーメッセージで早合点した:「パストラバーサル検知」という物騒な言葉に引きずられて、最初は「自分のアカウントが怪しい扱いされてる?」と身構えました。実態は、こちらの保存場所と向こうの想定保存場所がズレていただけ。強そうなメッセージほど、落ち着いて切り分けるのが近道です。

    まとめ:片付けは、関係者全員に言ってからやる

    一連のトラブルでわかったのは、Coworkの中で「このフォルダはこの用途」という合意(canonical path)が静かに効いているということでした。spaces.json にあるマウント情報はあくまで表札で、スケジューラはスケジューラで「本当の置き場所」を別に持っている。表札だけ書き換えると、引っ越したつもりのタスクが住民票だけ残された状態になる。

    整理自体はいいことだし、やって良かったと思います。ただ次からは、何を動かすと誰が困るか を先に確認してから手を出します。部屋で言えば、自分の机を片付ける前に「ルンバ、ちょっとこっちは避けてね」と声をかけておく、みたいな話。

    とはいえ、壊してみて初めて見えた仕組みが多かった。「見てから動かせ」が正論だけど、「動かしてから見える」ことも多いな、と今日は思いました(負け惜しみではないです、たぶん)。


    関連リンク

  • Proと Claude Code ー SNSのスクショを一次情報で確かめてみた

    Proと Claude Code ー SNSのスクショを一次情報で確かめてみた

    タイムラインで見かけた一枚のスクショ

    昨日、Xをぼーっと眺めていたら、「新規で Pro に入っても Claude Code は使えないらしい」という投稿と、Anthropic 公式の価格ページらしきスクリーンショットが流れてきた。Claude Code の欄に ×印 が並んでいる画像つきで、リポストもそこそこ伸びていた。

    開発経験ゼロの私にとって、Claude Code は「いつかちゃんと触りたいやつ」リストの上位にいる機能だ。もしそれが Pro で使えなくなるとしたら、このブログの読者にも影響が大きい話になる。

    ただ、私はまだ Claude 歴6日のド初心者で、SNS のスクショ一枚を根拠にブログに書くほど自分の読解力を信じていない。というわけで、一次情報にあたってみることにした。


    結論マップ(噂/一次情報)

    SNSで見えていたもの一次情報で確認できたこと
    「新規 Pro で Claude Code が使えなくなる」公式ページでは現在も Pro に Claude Code が含まれると明記
    価格ページの Claude Code 欄に × 印のスクショ2026-04-21 に一時的な表示の揺れがあったあと、ページは元に戻されている
    既存ユーザーにも影響が出る読み方Anthropic の中の人が「既存ユーザーには影響なし」と明言

    実際は何が起きていたのか

    自分で公式ページを開いてみて、ざっくり3点にまとまった。ここからは全部、一次情報で裏が取れている話だけ書く。

    ひとつめ。今日時点(2026-04-22)の Anthropic 公式の料金ページ と Pro プランのページ には、Pro プランの機能一覧のなかに「Includes Claude Code」と書かれている。Claude Code のセットアップを解説している 公式ドキュメント にも、「Claude Code requires a Pro, Max, Team, Enterprise, or Console account.」とある。つまり Pro は、Claude Code を使える前提のプランとして案内されている。

    ふたつめ。2026-04-21 の夕方ごろ、その Pro の機能一覧から「Claude Code」の表記が一時的に消えていた時間帯があった。スクショで出回っていたのはおそらくこの瞬間の画像だ。表記は数時間のうちに元に戻されている。

    みっつめ。Anthropic の Head of Growth、Amol Avasare 氏が X で公式に説明している。要点だけ訳して引用すると、「新規のプロシューマー向け登録のうち約2%に対する小規模テストを実施中で、既存の Pro・Max 加入者には影響しない」。裏返すと、新規で Pro に入った人のうち 98% は今までどおり Claude Code を使えるということになる。


    まず、既存の Pro ユーザーは心配しなくていい

    この記事にたどりついた人の多くは、「自分の契約、巻き込まれてるのでは」と不安になって検索してきた方だと思う。細かい話に入る前に、いちばん伝えたい結論から書く。

    既存の Pro・Max 加入者は、今回の件では影響を受けない。

    これは私の推測ではなく、Anthropic の Head of Growth である Amol Avasare 氏本人が X で明言している こと。さらに同じ投稿で、「将来的に料金体系が変わる場合も、既存ユーザーには事前に告知する」 とも書かれている。ある朝ログインしたら Claude Code のタブがごっそり消えていた、という種類の事件には少なくとも今回はならない、ということだ。

    ただし、ここは太字で釘を刺しておきたい。この「影響を受けない」はあくまで現時点の方針であって、恒久的な保証ではない。 今回走っているのは A/B テストなので、結果次第では将来、既存ユーザーにも何らかの形で影響が及ぶ可能性は当然ある。「事前に告知する」のほうも、あくまで Anthropic 側の現在のスタンスであって、仕組みとして約束されているわけではない。この方針が続く保証はない、というところは頭の隅に置いておきたい。

    だから、今日時点で契約をいじる必要はない。解約も、上位プランへの慌てた乗り換えも、今日時点では早すぎる。ただし「ずっと安泰」という話でもないので、Anthropic 側の続報にちゃんと気付ける程度には公式発信をフォローしておく——くらいの警戒は残したまま、普段どおり使っておくのがちょうどいい塩梅だと思う。


    それはそれとして、「やり方」にはひっかかる

    ここからは初心者の分際で意見を挟むパートなので、お手柔らかに願いたい(先に謝っておく)。

    今回 Anthropic は、Pricing ページとサポートドキュメントの両方で、Pro から Claude Code の表記を一気に外した状態のまま表示していた時間帯があった。公式ページの表記変更はそれ自体がひとつのプレスリリースに近い重みがあって、見た人が「正式な方針変更」と受け取るのは自然な流れだ。にもかかわらず、事前のアナウンスは見当たらず、SNS が騒ぎ始めてから「これは2%対象の小規模テストです」と補足が入る順番だった。あとから小規模テストと言い始めるあたりやり方がセコい。 表示を変えた瞬間から、既存ユーザーが不安になり、新規契約を止めて様子見する人が出てくる時間が確実に発生していたはずで、そのコストは誰が払うんだろうと少し思う。

    もうひとつ、今回 X で話題が大きくなった構造のほうも、冷静に見ておきたい。スクショ一枚は、撮影時刻も、その後にページが元に戻ったことも、映らない。「今の公式の姿」ではなく「ある瞬間の切り抜き」なのに、リポストで広がるあいだに時間軸の情報はどんどん落ちていく。バズの燃料として相性が良すぎるぶん、正確性は置き去りにされやすい。ただこれは投稿者個人の性質というより、公式側の事前アナウンスがあれば起きなかった類の騒ぎだと思う。投稿者の振る舞いを責めるより、発信設計の問題として見たほうが次につながるというのが、今回の私の立場だ。


    自分で確かめたい人向けのチェック手順

    プラン情報や価格は頻繁に変わるので、「記事の日付」と「自分が読んだ日」がズレている可能性を前提に、直接開いて見るのがいちばん早い。私がやった手順を残しておく。

    1. claude.com/pricing を開き、Pro の機能一覧に「Claude Code」があるか確認
    2. claude.com/pricing/pro も念のため開いて同じ文言があるか確認
    3. support.claude.com の Pro プラン解説 を開いて、Claude Code の項目が記載されているか確認
    4. code.claude.com/docs/en/setup の Authenticate の項を見て、対応プラン一覧に Pro が含まれているか確認
    5. 可能なら、Anthropic の公式発信(ブログや中の人の X)に更新情報が出ていないか検索

    ちなみに、普段こういう頼み方で Claude Code を動かしている

    今回は「公式ページを見る」寄りの話ばかりになってしまったので、バランスとして普段生産的に使っている頼み方も3つだけ残しておく。入力するファイルと返してほしい成果物の形をはっきり書くと、開発経験ゼロの私でも Claude Code はちゃんと応えてくれる、という手触りだけ共有しておきたい。

    散らかった Markdown メモを棚卸しする

    C:\Users\(私)\Documents\memo フォルダ配下の .md を全部読んでほしい。
    タイトル行(# で始まる1行目)が抜けているファイルを洗い出す。
    抜けている場合は、本文冒頭の1段落からタイトル案を1つ提案する。
    結果は「ファイル名 → 提案タイトル」の表形式で返す。

    💡 下書きが散らかりがちなときに使う。タイトル未設定のメモが一覧で可視化されて、そのまま一括で直せる状態になるのがありがたい。

    バッチファイルを書いてもらう

    毎朝やっている「特定フォルダのバックアップ」を .bat にしたい。
    C:\Users\(私)\Documents\work を、同じ階層の backup\YYYY-MM-DD\ に
    コピーするスクリプトを書いてほしい。
    30日より古い backup サブフォルダは自動で削除する仕様。
    コメントは日本語、Windows の CMD で動くこと。

    💡 仕事で「毎日同じ操作を繰り返している」部分をバッチ化したいときの定番。架空のフォルダ名でもそのまま動く形で返してくれる。

    既存スクリプトのコードレビュー

    scripts/daily_report.gs を読んでほしい。以下3観点でレビューする。
    - 例外処理が抜けている箇所
    - 外に漏れたら困る値(トークン・URL等)のベタ書き
    - 変数名・関数名の読みづらさ
    指摘は番号つきで、修正案はそのあとに別枠でまとめて書く。

    💡 自分で書いたコードを他人の目で読んでもらう感覚に一番近い。非エンジニアの自分が一番恩恵を感じた頼み方で、心理的にも頼みやすい。


    今回つまずいたところ

    • スクショの時刻が書かれていない投稿を鵜呑みにしそうになった: 投稿文に「さっき」「たった今」と書いてあっても、本当にさっきかは画像からはわからない。自分で今のページを開くほうが早い。
    • 「公式に見える画像」=「最新の公式」ではない: 今回のように、一時的な表示変更の瞬間を切り取られていることもある。疑うのは投稿者ではなく、「画像が示している時間軸」のほうだと今回気づいた。
    • 報道記事だけで完結させない: The Register などの報道は経緯の把握には便利だったが、「Pro で使えるかどうか」の答え自体は公式ページを自分で開いて確認した。報道は背景、公式は結論、と分けるのがよさそう。

    新規で Pro を検討している人向けの注意点

    大多数の新規加入者はそのまま Claude Code を使える。ただし 約2%の A/B テスト対象になる可能性だけは頭の隅に置いておくといい。もし契約直後に「自分は Claude Code が使えない側だった」と気づいた場合は、サポートに問い合わせるのが早道。無言で解約する前に、まずは公式アカウントの発信をフォローして最新状況を確認するくらいで十分だと思う。


    「罪を憎んで人を憎まず」という諺は、「人格」を嫌うのではなく「言動」の更生を目指せという意味だ。そういう意味では、私は Claude もとい Anthropic を「お気に入り」だが、今回の言動については「憎いほど」なので、是非とも更生してほしいところだ。


    関連リンク(一次情報)

  • プラン・料金 ー 最初に全部知っておけばよかった

    プラン・料金 ー 最初に全部知っておけばよかった


    先に言っておく

    「Claudeって無料で使えるの?」

    これ、最初に全人類が思うやつだと思います(たぶん。私調べ)。私も登録ページを開いた瞬間にそう思いました。で、調べてみたら想像より全然ちゃんと設計されていて、「あ、これはちゃんと選んだほうがいいやつだ」とじわじわ気づいた話をします。


    結論マップ(ビフォー/アフター)

    改善前(Before)改善後(After)
    「有料なの?どのプラン?」でフリーズ用途に合わせて3分で選べる
    Proにしたほうがいい?よくわからない始めるならFreeで十分、必要になったらProへ
    料金が怖くて登録をためらう無料でもちゃんと使えることがわかった

    ざっくり言うと

    Claudeには大きく分けて 5つのプラン があります。

    個人向け3種類(Free・Pro・Max)と、仕事向け2種類(Team・Enterprise)。

    「名前がシンプル……」と思ったあなた、そうなんです。内容も、読めば3分で判断できます(その3分間が今ここです)。


    Free(無料)

    • 料金:$0
    • 使えるモデル:全モデル(Opus 4.7・Sonnet 4.6・Haiku 4.5)
    • 主な機能:チャット・コード生成・画像認識・Web検索・ファイル作成・Slack連携・Google Workspace連携
    • 制限:使用量に上限あり(混雑時に制限がかかることも)

    これだけ使えて無料。最初に見たとき「どこかで課金される仕掛けあるよね?」と思って2回読み返しました。本当に $0 です。「ひとまず触ってみたい」という方は、間違いなくFreeから始めてOK。


    Pro(個人有料)

    • 料金:月額 $17(年払い)または $20(月払い)
    • Freeの機能すべて+使用量が大幅に増える
    • 追加機能:Claude Code・Claude Cowork(←私が今使っているやつ)・Research機能・Excel/PowerPoint生成(ベータ)

    「毎日本格的に使いたい」「Claude Code/Coworkを使いたい」という場合はPro一択です。

    ちなみに私もProです(ここで白状しておきます)。


    Max(ヘビーユーザー向け)

    Maxには2種類のプランがあります。

    プラン料金使用量(Proとの比較)
    Max 5x月額 $100Proの5倍
    Max 20x月額 $200Proの20倍

    共通機能:ピーク時も優先接続・早期機能アクセスあり。Claude Code・Coworkも含む。

    「Proの制限に毎日ぶつかる」という方向け。2種類あること、そして価格が倍違うことを最初から知っておくのが大事です。Max 5x($100)からスタートして、それでも足りなければMax 20x($200)へ移行する——が自然な流れです。私は……まだその段階ではないです(正直に申し上げます)。


    Team(チーム向け)

    Teamプランはシート(席)の種類が2つあります。

    シートの種類年払い月払い
    スタンダード$20/席/月$25/席/月
    プレミアム$100/席/月$125/席/月

    5〜150人のチームで使えるプランです。SSO(シングルサインオン:1つのID・パスワードで複数サービスにまとめてログインできる仕組み)・管理者機能・集中請求など、ビジネス導入向けの機能がついています。

    「会社でチーム導入したい」という場合はこちらへ。個人ブログを書いているだけの私には関係なかったですが、将来チームを持ったらまた来ます(壮大な話をしました)。


    Enterprise(大規模・セキュリティ重視向け)

    • 料金:$20/席+使用量
    • 追加のセキュリティ機能:ロールベースアクセス(=担当者ごとに使える機能を制限できる仕組み)・監査ログ・IPホワイトリスト(=アクセスを許可するIPアドレスを絞れる設定)など
    • HIPAAオプションあり(HIPAA:米国の医療情報保護法。医療機関がデータを扱う際に必要な要件)

    このブログで扱う範囲をきっぱり超えているのですが、「大企業・医療・金融などセキュリティ要件が厳しい業種」が使うプランだと思っておけばOK。


    実際にどう選ぶか

    迷ったら2つだけ確認してください。

    1. 個人で使うか、チームで使うか
    2. 毎日ガッツリ使いたいか、ちょっと試したいか

    これで絞れます:

    状況おすすめプラン
    まず触ってみたいFree
    毎日本格的に使いたい・Claude Code/Coworkを使いたいPro
    Proの制限にたまにぶつかるMax 5x($100/月)
    Proの制限に毎日ぶつかる・本格的に使い倒したいMax 20x($200/月)
    会社・チームで導入したいTeam
    大規模・セキュリティ要件ありEnterprise

    「やっぱりわからない」という場合は、Freeで始めてください。本当に。制限に引っかかってから考えれば十分です。


    試してみたプロンプト

    Freeプランで登録直後に打ったプロンプト例です:

    私はプログラミング初心者です。
    Pythonで「Hello, World!」を表示するコードを書いてください。
    コードの各行に日本語でコメントをつけて、初心者でもわかるように説明してください。

    💡 ポイント: 「初心者向け」「日本語で」「各行にコメント」と具体的に書くと、Claudeの回答がグッとわかりやすくなります。試しに条件を何も書かずに同じプロンプトを打ってみてください——差に驚きます。


    私が間違えたこと


    • 「Proにしないと全モデルが使えない」と思っていた:FreeでもOpus 4.7を含む全モデルが使えます。「制限されるのは量であって、機能ではない」というのを最初に知りたかった。30分調べてから気づきました(30分返して)。



    • 「年払いと月払いの差を気にしていなかった」:Proは月払いで $20、年払いだと月 $17 です(年間 $36 の差)。ニーチェは「私を殺さないものは私を強くする」と言いましたが、年払いを選ぶというのはそういう——未来の自分への $36 の賭けです(そこまで大げさな話ではない)。続けるつもりなら最初から年払いのほうがお得。



    • 「Maxは最初から候補に入れなくてよかった」:Proを使い込んで制限にぶつかり始めてから検討する、で十分でした。いきなりMaxを選ぶ必要はなかった。また、MaxにはMax 5x($100/月)とMax 20x($200/月)の2種類があります——最初からMax 20xを選ぶ必要はありません。



    で、結局どうなの

    始めるならFree、本格的に使うならPro。これで9割の人は事足りると思います。

    Claudeは無料でもちゃんと使えます。「有料かどうか怖くて登録できていない」という方がいたら、まずFreeで登録してみてほしい。制限に引っかかってから考えれば十分です。

    「月 $20 が高い」という気持ちはよくわかります。私も使い始める前はそう思っていました。使い始めたら……まあ、元を取ったどころかぐるぐる回っている気がします。でも後悔はしていない(断言)。


    関連リンク

  • Gmail MCP ー つながってたのに、全然使ってなかった

    Gmail MCP ー つながってたのに、全然使ってなかった


    先に言っておく

    GmailがCoworkにつながってるの、知ってた?

    私は知ってた。設定画面に「Gmail」ってしっかり書いてあったから。でも「なんか怖いな……本当にメール読まれちゃうの?」と思い続けて、ずっと無視してた。設定画面を開いては、そっと閉じる謎の行動を繰り返すこと数週間。

    ようやく試した結果——思ったより普通に便利だった。怖がり損だった(3週間返してほしい)。


    結論マップ(ビフォー/アフター)

    改善前(Before)改善後(After)
    Gmailの検索窓でキーワードをポチポチ入力Claudeに「〇〇の件のメール探して」と頼む
    返信文をゼロから考えて書く「こんな内容の返信下書きして」とお願いする
    ラベル一覧は画面をスクロールして確認「ラベル一覧と ID 教えて」で即取得

    これが本体

    MCP(Model Context Protocol) とは、ClaudeがGmailなどの外部サービスと「会話」できるようにするための接続規格です。

    ……「規格」と書くと突然お堅い感じになりますね(私も書きながらそう思った)。

    もっと簡単に言うと、「Claude にGmailの鍵を渡して、代わりにメールを調べたり下書きを作ってもらう仕組み」です。完全に理解しました(3回目)。

    Gmail MCPで使える主な機能はこの3つ:

    • メールスレッドの検索 — 「〇〇さんからのメールを探して」など
    • 返信下書きの作成 — 「〇〇の内容で返信の下書きを作って」など
    • ラベル一覧の取得 — Gmailのラベル名と ID をまとめて確認

    大事な注意点が1つ:メールの「送信」はできない。

    Claudeができるのは「下書きを作ってGmailの下書きフォルダに保存する」まで。送信は自分の目で確認してから自分のボタンで押す、というルールになってます。勝手に送られるわけではないので、安心してください。私はそこを誤解して3週間ビビり続けていました(返ってこない時間)。


    実際にやった手順

    Coworkですでに Gmail が接続済みの場合は、手順1〜2 だけで使えます。

    1. Coworkを開く(Claude Desktop AppのCoworkモード)
    2. チャットで「GmailのMCPが使えるか確認して」と入力して動作確認
    3. 未接続と言われた場合:Coworkの設定画面(Connectors・コネクター設定)からGmailを追加する

    私は手順2で「はい、使えます」という反応が来たので(意訳)、すぐにそのまま試せた。

    接続確認のプロンプトはこれ:

    試してみたプロンプト

    ① メールスレッドを検索する

    「請求書」というキーワードを含むメールスレッドを最新5件探して、
    件名・送信者・受信日時を教えてください。

    💡 ポイント: search_threadsが動き、件名・差出人・受信日時が返ってくる。Gmail検索窓に打つ文字列をそのまま日本語で頼む感覚でOK。

    ② 返信の下書きを作る

    メールID: 〈search_threadsで取得したIDをここに貼る〉
    このメールに対して、「来週の火曜日午後2時に対応します」という内容で
    丁寧な日本語の返信下書きを作成してください。

    💡 ポイント: create_draftが動く。作成された下書きはGmailの「下書き(Drafts)」フォルダに保存される。送信は自分で確認してから行う。


    やらかしたこと


    • メールIDってなに?と詰まった: 最初「メールID」の意味がわからなかった。search_threadsで検索→返ってきたスレッドIDをコピー→create_draftに貼る、という2ステップが必要。順番を守れば大丈夫。



    • 「下書きが保存された!」と青ざめた: 「下書きを作って」とお願いしたら、本当にGmailの下書きフォルダに保存されていた。一瞬「え、勝手に送られた!?」と焦ったが、ちゃんと下書きのままだった。ほっとするまで5秒かかった(動悸)。



    • Coworkを再起動したら治った: 「接続できません」と言われて焦ったが、Coworkを再起動したら普通に動いた。最初の一手はとにかく再起動、という教えを胸に刻んだ。



    で、結局どうなの

    「Gmailを開かずにメールを操作できる」 は地味に便利だった。

    メール検索って、毎回思ったより時間を使うんですよね。「いつのメール?」「誰から来てた?」でGmailの検索窓をポチポチするより、Claudeに「〇〇の件のメール探して」と書く方が速い。

    返信下書きは、「ゼロから文章を考える」という一番エネルギーを使う作業をClaudeに丸投げできるので、精神的コストがかなり下がる。

    それにしても、最初から「送信はできない・下書きまで」と知っていれば、あの3週間の謎の逃避行動はなかったのだが——。まさにシュレーディンガーの連携。確認するまで「便利なのか怖いのかわからない重ね合わせ状態」が続き、確認した瞬間に「ただの便利ツール」に収束した(量子力学の話)。

    確認しないと損するのは私、という結論に至った。


    関連リンク