タグ: トラブルシューティング

  • ハルシネーション ー AIの「もっともらしい嘘」に2回ひっかかってから付き合い方を変えた

    ハルシネーション ー AIの「もっともらしい嘘」に2回ひっかかってから付き合い方を変えた


    「やけに堂々と間違えるな、この人…」

    AIを使い始めた最初の週、私はChatGPT時代から数えて2回、見事に騙された。

    1回目は、ある法律の条文番号を聞いたら実在しない条文を返してきた。書きぶりがあまりに堂々としていて、私は何の疑いもなく職場のメモに転記した。後日、同僚から「その第何条、どこにあるんですか」と聞かれて初めて気づいた。
    2回目は、ある書籍のタイトルと出版社を尋ねたら、ありそうな書名と実在の出版社をセットで返してきた。書名で検索したら一件もヒットしない。出版社のサイトでも見つからない。AIの中だけに存在する本だった。

    これがハルシネーションだ。中世の城下町で「あそこの井戸の底に金貨が埋まってる」と自信満々に語る吟遊詩人みたいなもので、節回しが立派なほど信じてしまう。

    💡 ハルシネーション(hallucination)とは、AIが事実と違うことを、もっともらしい言い回しで生成してしまう現象のこと。「幻覚」と訳されるが、AIが幻を見ているわけではなく、統計的に「次に来そうな単語」をつなげた結果、内容まで創作してしまった状態を指す。


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

    場面知る前の私知った後の私
    法律・制度の質問そのままメモに転記出典を聞き返す or 自分で公式サイトで照合
    書籍・論文の引用書名・著者をそのまま信じる検索で1件もヒットしないなら疑う
    「最新の〇〇は?」即答を鵜呑み「いつ時点の情報?」と必ず聞き返す

    「Claudeに聞いたから」をその場の最終決定にしない。これだけで2回目の同僚チェックを生き延びられる。


    ハルシネーションって、要は何

    Anthropic公式のヘルプセンターには、Claudeの回答が間違うことについてはっきり書いてある。要点を引くと、こうだ。

    In an attempt to be a helpful assistant, Claude can occasionally produce responses that are incorrect or misleading. This is known as “hallucinating” information.
    (役に立とうとするあまり、Claudeはときどき不正確だったり誤解を招く回答を返すことがある。これを「ハルシネーション」と呼ぶ)

    そして、起こる典型的なパターンとして公式は2つ挙げている。

    1. 最新情報に追いついていない場面:訓練データのカットオフより後の出来事を聞かれると、Claudeは混乱しやすい。
    2. 権威ありげな引用の捏造:実在の本・論文・条文に見える引用を生成してしまうことがある。「もっともらしく見えるが、根拠がない」のが厄介な特徴。

    IPA(独立行政法人情報処理推進機構)の「AI利用者のためのセキュリティ豆知識」(2025年12月版)にも、生成AIの仕組みとして「情報の正しさを検証しているのではなく、統計的に次に続く確率が高い単語をつなげて文章を作る」と整理されている。事実より文章の自然さを優先する仕組みなので、精巧な嘘ほど作りやすいということになる。


    やってみるとこうなる:私の実例2件

    ケースA:架空の条文事件
    私「〇〇法の第◯条、どんな内容?」
    AI「第◯条は、…と定められています。実務では…の運用が一般的です」
    → 同僚に確認されて再検索。条文番号自体が存在しなかった。条文のあるべき形式(「〜について次の各号に掲げるとおりとする」みたいな言い回し)はそれっぽかったのに、中身は0%実在しなかった。

    ケースB:架空の書籍事件
    私「家計管理の入門書でおすすめは?」
    AI「『はじめての家計簿』(〇〇出版・著者×××・2019年刊)が定番です」
    → 出版社のサイトに該当書籍が無い。著者名で検索しても別人しか出てこない。書名・著者・出版社・年がバラバラに正しいけど、組み合わさった本は実在しない。

    どちらも共通していたのは、「自信のある言い切り」「具体的な固有名詞」「もっともらしい背景説明」がセットになっていた点だった。AIが断定的に語るときほど、中身を疑った方がいい、というのが私の学習結果。


    公式が勧めている付き合い方(プロンプト編)

    Anthropicのプロンプトエンジニアリングガイド(”Reduce hallucinations”)には、ハルシネーションを減らすための工夫がいくつか紹介されている。私が試して効いたのは、次の3つだった。

    1. 「分からない」と言ってよいと先に伝える

    回答に確信が持てない場合は、「分かりません」と答えてください。
    推測で具体的な数字や固有名詞を埋めないでください。

    このひと言を冒頭に足すだけで、雰囲気で答えてくる頻度が減る。Anthropic公式も “Allow Claude to say “I don’t know”” として推奨している。

    2. 出典を一緒に出させる

    家計簿アプリで使える日本の家計調査の公的データを教えてください。
    - 各データについて、出典(公的機関名・URL)を一緒に明記してください。
    - URLが思い出せない場合は、データ名と発行機関のみを書き、URLは「不明」と明記してください。

    「URLを必ず書け」だけだと、URLまで創作される。「分からないなら不明と書け」までセットで指示するのがコツだった。

    3. 引用は原文のまま抜くよう頼む

    長い文書を渡してClaudeに要約させるとき、「まず該当箇所を原文ママで引用してから、要約してください」と頼むだけで、根拠のない言い換えが目に見えて減る。Anthropic公式もlong documents向けの定番手順として紹介している手法。


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

    • 「Claudeに聞いた」を出典にしない:高校の先生に教わった「孫引きはダメ」がそのまま当てはまる。Claudeが見せてくれたURLは、自分で開いて中身を確認するまで存在を信じない
    • 断定形ほど疑う:「〜です」「〜が定番です」と歯切れがいいときほど一拍置く。逆に「〜の可能性があります」「公開情報では確認できませんでした」と濁してくれたら、それはちゃんと不確実性を伝えている良い兆候
    • 最新情報はAIに聞かない方が早い:Claudeには知識のカットオフがある。「今月の〇〇は?」「昨日のニュースで…」みたいな質問は、Web検索を有効にするか、自分で公式サイトを開いた方が確実
    • 法律・医療・金銭はダブルチェック前提:公式も “should carefully scrutinize any high-stakes advice”(重要な助言は慎重に精査せよ)と書いている。AIは下書きや整理係として優秀だが、最終確認はAIにさせない

    まとめ

    ハルシネーションは「AIが時々起こす不具合」ではなく、今のAIの仕組みそのものに組み込まれた性質だ。完全には消えない。だから「無くす」方を目指さず、気づける側に立つのを目指すのが現実的な落とし所だった。

    私がこの2週間で身についたのは、ほんとに小さな3つだけ。断定形を一拍疑う/出典をセットで出させる/重要なことは自分で1ソース照合する。これだけで、職場のメモを書き直す回数がだいぶ減った。

    IPAの豆知識ページに、AIの付き合い方として「発展途上の新人だと思って使いましょう」という言い回しがあって、私はこれが一番しっくりきた。新人は素直で物覚えがよくて頼りになるけど、重要な書類のサインまでは任せない。AIとの距離感も、いまのところ、それくらいでちょうどいい。


    関連リンク(一次情報)

  • チェックポイント ー 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回でいいってよ。


    関連リンク

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

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

    整理整頓、こわい

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

    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 にあるマウント情報はあくまで表札で、スケジューラはスケジューラで「本当の置き場所」を別に持っている。表札だけ書き換えると、引っ越したつもりのタスクが住民票だけ残された状態になる。

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

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


    関連リンク

  • Claude Code CLI ー ターミナル、ずっと怖いと思ってた

    Claude Code CLI ー ターミナル、ずっと怖いと思ってた

    始めるまでが全部

    「Claude Codeって何?」と聞かれたら、ブログ名で使っておきながら「……Cowork で使ってるやつです」とごまかしていた私に、向き合う日が来てしまいました。

    Claude Code には、CLI(コマンドラインインターフェース)版というものがあります。ターミナル(=黒い画面に文字を打ち込むやつ)から使うタイプです。Cowork はそのデスクトップアプリ版、CLI版はターミナルから直接動かすもの。どちらもClaude Code ですが、使い方がまったく違います。

    「ターミナル、怖い」——正直そう思っていました。でも実際やってみたら、インストール自体はコマンドを1行コピペするだけでした。拍子抜けするくらい。怖かったのは始める前の自分だけでした。(始める前の自分に言ってやりたい。本当に)


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

    改善前(Before)改善後(After)
    Claude Code CLI の存在は知っているが触っていないインストール済み、ターミナルで claude と打つと動く
    「ターミナル = エンジニア専用の世界」だと思っていたコマンド1行コピペでセットアップ完了
    Cowork と CLI の違いが曖昧役割の違いを理解した上で使い分けられる

    これが本体

    Claude Code CLI(クロード・コード・シーエルアイ)は、ターミナルから Claude に話しかけながらコードを書いたり、ファイルを操作したりできるツールです。

    CLI(コマンドラインインターフェース)とは、黒い画面に文字を打ち込んでコンピューターを操作する方法のことです。「コマンドプロンプト」「PowerShell」「ターミナル」が全部これ系。マウスをほとんど使わない世界です。エンジニアが格好よく使っているあれ、です。

    Cowork との違いをざっくり言うと、Cowork はデスクトップアプリ、Claude Code CLI はターミナルツール。Cowork は画面があってボタンもある、CLI はコマンドを打って動かす。どちらも Claude がいて助けてくれるのは同じですが、向いている使い方が違います。

    「じゃあ Cowork があれば CLI いらないじゃないか」と思いますよね。私も思いました。でも CLI版にしかできることもあって、たとえばほかのツールとの連携や、もっとエンジニアっぽいワークフローは CLI が得意です。あと、「使えた」というだけで少し自信がつく——これが意外と馬鹿にできません(重要)。


    実際にやった手順

    ⚠ 注記: ここで紹介するインストール方法は、記事作成時点(2026-04-23)のものです。Claude Code は更新頻度が高いので、将来的に手順やコマンド、対応プランなどが変わっている可能性があります。うまくいかないときは Claude Code セットアップ詳細(公式) の最新版も合わせて確認してください。

    まず確認しておくこと(超重要):
    – Pro / Max / Team / Enterprise プランが必要(Claude.ai の無料プランは Claude Code が使えません)
    – Windows の場合は Git for Windows が必要(後述します)

    1. Git for Windows をインストールする(Windows のみ)

    まず Git for Windows(公式) をダウンロードしてインストールします。「Git って何?」と聞かれると説明が長くなるのですが、Claude Code が内部で使う仕組みが入っているので必要です。コードのバージョン管理ソフト——と覚えておけば今は十分です。

    インストール中に設定画面がいくつか出ますが、基本的にデフォルト(そのまま Next)で進めて問題ありません。「全部読もう」とすると30分かかります。読まなくていい(読みませんでした。ごめんなさい)。

    2. ターミナルを開く

    Windows では「PowerShell」または「コマンドプロンプト(CMD)」を開きます。スタートメニューで「powershell」と検索すると出てきます。

    ここで大事なのが「自分が今どちらを使っているか」の確認です——これが最初の罠です。

    • PowerShell の画面: PS C:\Users\あなたの名前> という感じで PS がつく
    • CMD の画面: C:\Users\あなたの名前> という感じで PS がつかない

    どちらを使うかで次のコマンドが変わります。間違えると「コマンドが見つかりません」エラーが出て、「え何が違うの……」と5分悩む羽目になります(なりました)。

    3. インストールコマンドを実行する

    コマンドをコピーして画面に貼り付けて、Enter を押すだけです。「たったこれだけ?」と思うくらい短いです。

    現在(2026-04-23時点)のインストールコマンドは以下です。 公式の案内は更新されることがあるので、コマンドだけコピペする場合も時期によっては最新版を 公式セットアップページ で確認してください。

    PowerShell の場合:

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

    CMD の場合:

    curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd
    

    自動でダウンロードとインストールが始まります。完了するまで少し待ちます。「何も起こっていないのでは」と不安になる時間がありますが、動いています。信じて待つ。

    4. バージョンを確認する

    claude --version
    

    バージョン番号(例:2.1.89 みたいな数字)が出てきたら成功です。やった。画面に claude と入力しただけで Claude が動いた——小さいことですが、なんか感慨深かったです。

    command not found みたいなエラーが出た場合は後述のつまずきポイントを確認してください。

    5. ログインして使い始める

    claude
    

    初回はブラウザが開いてログイン画面が出ます。Claude アカウントでログインすると、ターミナルに戻ってきます。あとは話しかけるだけ——ここから先は Cowork と同じ感覚です。


    動いた設定をそのまま

    プロジェクトのフォルダに移動してから以下を打ってみてください。

    what does this project do?

    💡 ポイント: プロジェクトのフォルダ内でこのコマンドを打つと、Claude がフォルダ内のファイルを読んで「何するプロジェクトか」を説明してくれます。英語で打っても日本語で返ってきます(私の場合は)。「フォルダ内に何もない」場合は適当なテキストファイルを置いてから試してみてください。

    インストール直後に確認しておくと便利なコマンドはこのあたりです:

    claude --version     # バージョン確認
    claude doctor        # インストール状態を診断してくれる
    

    claude doctor は問題があれば「ここがおかしいですよ」と教えてくれる診断コマンドです。お医者さんに行くより気軽に診てもらえる。「なんか動かない気がする」というときに最初に試すといいです。


    ここで止まった


    • 「irm が認識されない」というエラーが出た: PowerShell だと思っていたら CMD を使っていました。プロンプトに PS がついているかどうかで確認できます。PS C:\...> なら PowerShell、C:\...> だけなら CMD です。使っている側のコマンドを選んでください(これで30分悩んだのは内緒です)。



    • 「Git for Windows を入れ忘れた」: インストールは完了したのに claude コマンドを打ったら動かないことがありました。Claude Code は内部で Git Bash を使うので、Git for Windows がないと動きません。Claude Code より先に Git を入れておくのが正しい順番です。



    • 「無料プランで試そうとした」: Claude.ai の無料プランでは Claude Code が使えません。Pro 以上のプランが必要です。「なぜ動かないのか」で30分悩んでから気づいたので、先に確認しておくことを強くおすすめします(30分返してください)。



    • 「インストール後にターミナルを再起動しなかった」: PATH(=コマンドの場所をOSが探すための設定)が更新されないため、古いターミナルのままだと claude が見つからないことがあります。インストール直後に動かなかったら、ターミナルをいったん閉じて開き直してみてください。



    で、結局どうなの

    インストール自体は「難しかった」というより「なんか怖かった」という話でした。コマンドを1行コピペして Enter を押すだけなので、手順自体に難しいところはない。ただターミナルを開くまでの心理的なハードルが異常に高かった——それだけです。

    コロンブスが大西洋を渡ろうとしたとき、「海の果てに奈落がある」と信じていた人が多かったそうですが——開けてみたら普通に大陸がありました。CLI もだいたい同じ構造です。開けてみたら普通でした(怖くなかった、とは言えないけど。あの緊張感はなんだったんだ)。

    Cowork で Claude を使ってきた人は、CLI版を試すと「あ、中身は同じだ」とわかると思います。画面の見た目は全然違うけど、話しかけている Claude は同じです。どちらが向いているかは作業スタイルや目的次第。まず使ってみる、が一番早い結論でした。

    ターミナルやエディタから Claude Code を使うことそのもののメリット——エディタ内で作業が完結する、普段のワークフローに自然に組み込める、複数ファイルを同時に扱える、など——もいろいろあるのですが、ここで書き始めると長くなるので別記事に譲ります。今回はインストールまで。使ってみての利点や Cowork との使い分けは別途解説する予定です。


    関連リンク