ノンエンジニアのClaude Code奮闘記 #6 CLAUDE.mdを育てる——AIへの「自分専用の取扱説明書」のつくり方

ノンエンジニアのClaude Code奮闘記 #6 CLAUDE.mdを育てる——AIへの「自分専用の取扱説明書」のつくり方

はじめに こんにちは、広報・制作担当のmeraです。 #3 ダウンロードフォルダ整理編で初めて CLAUDE.md を作りました。 あの頃のCLAUDE.mdは、こんなものでした。 # ルール- secrets/ は触らない - .env ファイルは触らない2行。以上。 それから約1ヶ月。 今の私のブログフォルダにある CLAUDE.md は、スクロールしないと読めない長さになっています。 「育っている」という感覚がいちばんしっくりきます。 失敗するたびにルールを追加して、うまくいったやり方を書き留めて、「自分専用のAI取扱説明書」みたいなものができていきました。 この記事は、その育て方の記録です。CLAUDE.mdの書き方に「正解」はありません。これは私のケースの話です。自分の仕事や使い方に合わせて、自由にアレンジしてください。この記事で学べることCLAUDE.mdが「なぜ必要か」の感覚的な理解 最初の1行から始める書き方 「失敗→追記」で育てていくサイクル 私が今使っているブログ用CLAUDE.mdの実例 フォルダごとにCLAUDE.mdを使い分ける方法そもそも CLAUDE.md って何をするもの? CLAUDE.mdは、そのフォルダでClaude Codeを使うときの「事前ルール」を書いておくファイルです。 人間で言うと、「引き継ぎ資料」や「業務マニュアル」に近い。 Claude Codeを起動するたびに読み込まれ、「このフォルダではこういうルールで動いてね」と伝えてくれます。 書かなくても動きます。でも書くと、同じことを毎回言わなくていい。 「触らないで」「この形式で出して」「私の文体を真似して」——こういう指示を一度書いておけば、次からは自動的に適用されます。「毎回同じことを説明するのが面倒だな」と感じたら、CLAUDE.mdに書くサインです。その感覚を大事にして、その都度追記していくのが、いちばん自然な育て方です。最初の1ヶ月: 「とにかく禁止事項だけ書いた」時期 使い始めたばかりのころ、私はCLAUDE.mdを「危ないことを止めるストッパー」として使っていました。 ダウンロードフォルダのCLAUDE.md: # ルール- secrets/ フォルダは触らない - .env ファイルは触らない - 実行前に、変更内容のリストを出すこと - ファイルを削除する場合は必ず確認を取ること最初はこれで十分でした。 「とにかく事故を防ぐ」フェーズ。 でも使っていると、「毎回同じ出力形式を指定するのが面倒」という不満が出てきます。 そこで次の一歩が始まりました。2ヶ月目: 「形式」と「お願いの型」を覚えさせた 議事録をまとめてもらうとき、毎回「決定事項・TODO・次回の議題候補の形式で」と書いていました。 これをCLAUDE.mdにコピペしたら、言わなくてよくなりました。 業務フォルダのCLAUDE.md(一部): ## 議事録まとめの形式以下の構成で出力してください。- **日時・参加者**:1行で - **決定事項**:番号つきリスト(各1〜2行) - **TODO**:担当者・期限・ステータスを表形式 - **次回の議題候補**:箇条書き禁止:- 感想・コメントを入れない - 「〜と思います」など推測表現を使わない - 上記以外のセクションを追加しないこれを書いてから「議事録まとめて」だけで同じ形式が返ってくるようになりました。 「あ、CLAUDE.mdって便利なやつかも」と思い始めたのはこのあたりです。転機: ブログ専用CLAUDE.mdを作った このシリーズを書き続けているうちに、「ブログの仕事はブログの仕事で、専用のルールがあると便利では」と気づきました。 ブログフォルダ(/blog-i-ailab/)専用のCLAUDE.mdを作り、私の文体・トーン・禁則事項を書き込み始めたのです。 これが、いちばん育てる楽しさを感じた段階でした。今のブログ用CLAUDE.mdの中身(実例) 現時点での私のブログ用CLAUDE.md、ほぼそのままお見せします。 # blog-i-ailab 執筆ルール(mera用)## 基本プロフィール- 書き手:mera(広報・制作担当、ノンエンジニア) - 読者:AIに興味があるが専門知識がない一般の方 - ブログのトーン:親しみやすく、正直。専門用語は使わない or 使うなら必ず説明## 文体ルール- 語尾は「です/ます」調に統一 - 箇条書きより、文章でつなぐことを優先する - 「〜してみました」「〜でした」という体験談の口調を大切にする - 難しい概念は「人間で言うと〜」「身近な例えで言うと〜」で言い換える## 禁止事項- 「実は」「なんと」などの煽り表現は使わない - 「〜すべき」「絶対に〜」などの断定的な言い方は避ける - 誇張した数字・効果の表現は使わない - アドバイス口調にしない(体験談スタイルを保つ)## 記事の構造- 冒頭:「こんにちは、meraです」から始める - 「この記事で学べること」セクションを入れる - h2 単位でCallout(info/tip/warning)を1〜2個入れる - 末尾に「次に読むのがおすすめの記事」と「参考文献・出典」を入れる## 触らないもの- src/config/ 以下のJSONファイルは変更しない - 他の著者の記事は編集しない - draft: true の記事は読み取りのみ、変更しない## よく使う指示- SNS用テキスト:Xポスト140字以内、ハッシュタグ2〜3個、URL末尾に[URL]と書く - リード文:200字以内、問いかけか情景描写で始める - 見出し案:5案、スラッシュ区切りで出す最初の4行から始まり、失敗と発見のたびに一行ずつ増えて、今この長さになっています。「完成」はありません。使うたびに「あ、これも書いておけばよかった」が出てきます。それでいい。育てることがCLAUDE.mdの正しい使い方だと今は思っています。フォルダごとに使い分けるのがコツ 私は今、こんな構成でCLAUDE.mdを置いています。フォルダ CLAUDE.mdの主な内容~/Downloads/ 触ってOK/NGの範囲、実行前確認ルール~/Documents/お仕事/ 議事録フォーマット、メール文体、禁止事項~/blog-i-ailab/ 文体・トーン・記事構造・禁則語~/AI実験/ 実験フォルダなのでルールなし。なんでも試す場所フォルダの性格に合わせて、内容がまったく違います。 「全部同じルール」にしないことで、それぞれの作業に最適化できました。「CLAUDE.mdに何を書けばいいかわからない」人へ 最初は本当に何を書けばいいかわかりませんでした。 今なら、こんな順番を勧めます。 Step 1: 「触らないでほしいもの」だけ書く 最初はこれだけで十分。フォルダ名・ファイル名を書いておく。 Step 2: 「毎回言っていること」を移してくる 「毎回この形式で出してって言ってるな」と気づいたら、コピペする。 Step 3: 「失敗した原因」を書き留める 「なんか違う結果が返ってきたな」と思ったとき、その「なぜズレたか」をルールとして書く。 Step 4: 「うまくいったときの条件」を書く 失敗だけでなく、「これを言ったらピッタリな結果が出た」というときも書き留める。 CLAUDE.mdを「正解を書く場所」ではなく「自分とAIの共同メモ」だと思うと、ハードルが下がります。CLAUDE.mdに書いたルールは「お願い」であって「強制」ではありません。複雑になりすぎると、Claudeがすべてを守れない場合もあります。大事なルール(触ってほしくないファイルなど)は、毎回の指示にも入れておくのが安心です。「AIを育てている」という感覚について CLAUDE.mdを書き続けていると、「AIを自分仕様にカスタマイズしている」という感覚が出てきます。 これは、ちょっと特別な体験でした。 最初は「すごいAIに従う」感覚だったのが、だんだん「私の好みに合わせて動いてくれる相棒」という感覚に変わってきた。 「あ、私の文体を覚えてる」「また全体をおさらいしなくて済んだ」——そういう瞬間が積み重なると、道具への信頼感が育ちます。 ノンエンジニアでも、コードを書かなくても、CLAUDE.mdを育てることでAIを「自分仕様」にできる。 それが、このシリーズで一番伝えたかったことのひとつかもしれません。まとめCLAUDE.mdは「AIへの事前指示」を書いておくファイル。毎回言わなくて済む 最初は「触ってほしくないもの」だけ書けば十分 「毎回言っていること」「失敗した理由」「うまくいった条件」を少しずつ追加していく フォルダごとに内容を使い分けると、それぞれの作業に最適化できる 「正解」はない。育てることがCLAUDE.mdの使い方Claude Codeの奮闘記も、気づけば6回になりました。 インストールで緊張していた自分が、今では毎日Claudeとブログを書いている。 変わったなあ、と、少し感慨深い気持ちです。 次回以降は、「失敗した話」や「3ヶ月の振り返り」など、もう少し正直な話を書いていこうと思っています。次に読むのがおすすめの記事ノンエンジニアのClaude Code奮闘記 #5 CLI・VS Code・Cowork——同じClaudeなのに何が違うの? ノンエンジニアのClaude Code奮闘記 #1 まずはインストール編参考文献・出典Claude Code 公式ドキュメント CLAUDE.md の書き方(Anthropic)

ノンエンジニアのClaude Code奮闘記 #5 CLI・VS Code・Cowork——同じClaudeなのに何が違うの?

ノンエンジニアのClaude Code奮闘記 #5 CLI・VS Code・Cowork——同じClaudeなのに何が違うの?

はじめに こんにちは、広報・制作担当のmeraです。 Claude Codeを使い始めてから約3週間。 インストール、プライバシー設定、ファイル整理、お願いの言い方——と積み上げてきた私は、ある日気づいてしまいました。「あれ……Claude Codeって、使い方が一種類じゃないの?」ターミナル版(CLI)、VS Code拡張、Coworkアプリ。 調べてみると、どれも「Claude Code」と呼ばれているのに、見た目も操作感もまったく違う。 「どれを使えばいいの?」という疑問がずっとあったので、今回は3つを実際に使い比べた結果を、ノンエンジニア目線で正直に書いてみます。この記事は2026年6月時点の情報をもとにしています。各ツールはアップデートが活発なので、最新の情報は公式ドキュメントでご確認ください。この記事で学べることターミナル(CLI)・VS Code拡張・Coworkの基本的な違い ノンエンジニアの広報・制作担当には、どれが向いているか 3つを使い分けるときの判断基準 私が今どれをメインにしているか、その理由まず:3つの「Claude Code」とは何か 少し整理しておきます。呼び名 何で動く 見た目ターミナル(CLI)版 Macのターミナルアプリ 黒い画面にテキストVS Code拡張 Visual Studio Code(エディタ) コードエディタの中にチャット欄Coworkアプリ Claude専用デスクトップアプリ チャット+タスク管理のGUIどれも「Claudeに指示してファイルを操作してもらう」という本質は同じです。 でも、使い心地は思った以上に違いました。ターミナル(CLI)版:はじめて会ったとき、一番怖かった #1 インストール編で最初に触れたのが、このターミナル版です。 cd ~/Documents/ブログ下書き/ claudeと打つと、ターミナルの中にClaude Codeのチャット画面が現れます。 良かったところ起動が早い。アプリを開く手間がない 「今ここのフォルダで作業したい」というとき、cd してすぐ始められる キーボードだけで完結するので、慣れると速いしんどかったところ文字だけの世界なので、ファイルが実際にどう変わったか視覚的に確認しにくい コピペ操作がちょっとクセがある 何かエラーが出たとき、その意味を解読するのに毎回ひと手間かかる 「ここのファイルを見せながら話したい」ができない私の結論:「ちょっとした作業をパパッとやりたいとき」向け。 慣れると便利だけど、ノンエンジニアが最初から快適に使える環境ではなかった正直なところです。ターミナルに慣れてくると、「あ、Macで文字を打って命令するって、こういう感じか」という体感が身につきます。怖いものじゃない——というのは、使い続けてから言える話でした。VS Code拡張:ファイルを「見ながら」話せる安心感 #3 ダウンロードフォルダ整理編で使ったのがこれです。 VS Codeを開いて、左サイドバー(Activity Bar)のSparkアイコンをクリックするとチャット欄が出てきます。 ファイルツリー(エクスプローラー)は左側に残したまま、Claude Codeをエディタタブとして開くこともできます。 良かったところファイルを「見ながら」話せるので、「このファイル」とか「この行の近く」という指示がしやすい 変更後のファイルをすぐ目で確認できる エラーが起きても、その場で原因を調べながら直してもらいやすい 「コードを書いてもらう」作業には、これが一番しっくりきたしんどかったところそもそもVS Codeに慣れていないと、起動するだけで面食らう 画面がゴチャゴチャして見える(エディタの機能を全部使いこなす必要はないのに) 「ブログ記事を書きたい」だけのときは、オーバースペック感がある私の結論:「ファイルを操作・整理する作業」のとき向け。 特に、何をやっているか目で追いかけたい慎重な作業には最適でした。Coworkアプリ:「対話する」ことに一番向いている Coworkは、Claude専用に作られたデスクトップアプリです。 見た目はチャットアプリに近く、左側にセッション履歴、右側にClaude との会話が表示されます。 初めて開いたとき、「あ、これがいちばん私に合っている」とすぐに感じました。 良かったところ画面がシンプル。「話す」ことに集中できる フォルダを選択して渡すと、その中のファイルを読んでもらえる タスクリストや進捗が見やすく表示される 「記事を書いてほしい」「調べてほしい」「まとめてほしい」という作業が一番やりやすい 選択肢を出して選ばせてくれる(AskUserQuestion的な動き)など、インタラクティブな操作が自然 ターミナルやVS Codeほど「開発者感」がなく、心理的な敷居が低いしんどかったところファイルを細かく操作するような作業は、ターミナルやVS Codeの方が向いている場面もある 「今起動しているフォルダの特定の行を直して」という細かいコード作業は、VS Codeに一歩譲る まだ機能が増えている段階なので、使い方が変わることがある私の結論:「ブログ記事を書く」「調査や要約をしてもらう」「アイデアを整理する」——広報・制作の仕事に一番フィットしていました。Coworkはフォルダへのアクセスを「選んで渡す」方式なので、「どのファイルを見せているか」がわかりやすい。プライバシー面でも、意図しないフォルダを渡してしまうリスクが減りました。3つの使い分け——私が今どうしているか 正直に言うと、今はCoworkをメインに使い、必要なときだけターミナルに戻るという使い方に落ち着きました。作業内容 私が選ぶツール 理由ブログ記事を書く・編集する Cowork 対話がスムーズ、タスク管理が見やすいSNS投稿文を作る Cowork 短文を何案か出してもらうのに向いているファイルを一括整理する VS Code拡張 変更をリアルタイムで目視確認したいちょっとした調査・要約 Cowork 画面がシンプルで集中できる特定のフォルダで素早く作業 ターミナル cd して即起動が速い何かコードらしいものをいじる VS Code拡張 ファイルツリーと見比べながらが安心「これしか使わない」と決めなくていいことがわかってから、気持ちが楽になりました。 道具は用途で選んでいい。「どれから始めればいいか?」という人へ もし今から始めるとしたら、私が勧める順番はこうです。まずCoworkを試す——ハードルが低く、チャット感覚で始められる ファイル整理をしたくなったらVS Code拡張——目で見ながら作業できて安心 速さが欲しくなったらターミナル——慣れてくれば一番素早い#1のインストール編でターミナルから始めたのは、順番として正しかったと思います。 「ターミナルでも動かせる」という自信があると、他のツールを使うときの底力になります。「Coworkが楽だからターミナルは要らない」というわけではありません。ターミナル版を触ったことがある、というだけで、エラーメッセージが出たときの対処力が変わります。怖がらず、一度は使ってみることをおすすめします。まとめClaude Codeには「ターミナル」「VS Code拡張」「Cowork」の3つの入口がある ターミナル:速くて軽い。慣れると強いが、視覚的なフィードバックが少ない VS Code拡張:ファイルを見ながら作業できる。整理・編集作業向き Cowork:チャット感覚。対話・執筆・調査・要約に最も向いている 広報・制作の仕事なら、まずCoworkから試すのがおすすめ 1つに絞らなくていい。用途で使い分けると、どれも活きてくる次回は、使い込むほど愛着が増す「CLAUDE.md」の育て方を書きます。 「最初はざっくり1行しか書いてなかったものが、いつの間にか自分専用の取扱説明書になっていた」という話です。次に読むのがおすすめの記事ノンエンジニアのClaude Code奮闘記 #4 「やって」しか言えなかった私が、細かく頼めるようになるまで ノンエンジニアのClaude Code奮闘記 #6 CLAUDE.mdを育てる——AIへの「自分専用の取扱説明書」のつくり方参考文献・出典Claude Code 公式ドキュメント Cowork モード紹介(Anthropic)

ノンエンジニアのClaude Code奮闘記 #4 「やって」しか言えなかった私が、細かく頼めるようになるまで

ノンエンジニアのClaude Code奮闘記 #4 「やって」しか言えなかった私が、細かく頼めるようになるまで

はじめに こんにちは、広報・制作担当のmeraです。 #3 ダウンロードフォルダ整理編を書いてから、Claude Codeをほぼ毎日使うようになりました。 インストールもできた、プライバシー設定も確認した、フォルダも片付いた。 「よし、次は仕事に使うぞ」と意気込んで、いざClaude Codeに向かうと——「……なんて頼めばいいんだ?」という壁に、静かにぶつかりました。 「やって」「書いて」「整理して」。それ以上の言葉が出てこない。 結果、Claudeから帰ってくるのはものすごく汎用的な回答で、「いや、そうじゃなくて……」とモヤモヤが残る。 この記事は、そこから少しずつ「うまいお願いの仕方」を身につけていった過程の記録です。 プログラマーが言うような「プロンプトエンジニアリング」の話ではなく、広報・制作の現場で使えるレベルの、等身大のお願い術です。この記事は体験記なので、完璧な正解を提示するものではありません。「こういう失敗をして、こう直したら良くなった」という記録として読んでもらえると嬉しいです。この記事で学べること「ざっくりお願い」が失敗しやすい理由 「条件・禁止・形式」の3点セットで頼む習慣 実際の失敗プロンプト→改善版の対比 「まずレポートだけ」「提案してから動いて」の2フレーズなぜ「やって」だと思い通りにならないのか Claude Codeは、曖昧な指示でも「なんとかしようとする」AIです。 「整理して」と言えば整理する、「書いて」と言えば書く。 でも、この「なんとかしようとする」が、実は曲者でした。 私が「整理して」と言ったとき、Claudeには次の情報が足りていない。何を基準に整理するのか(日付? 種類? 用途?) どこに移すのか(新しいフォルダ? 既存の構造に合わせる?) 動かしていいファイルと、触ってほしくないファイルの区別 最終的にどんな状態になっていれば「完成」なのかこの情報がない状態で「整理して」と言うと、Claudeは自分なりの解釈で動き始めます。 それが私の想像とズレていたとき、「なんか違う……」が生まれる。相手がAIでも人間でも、「お願いのうまさ」は変わらない気がします。後輩に仕事を頼むとき、「あとよろしく」だとやり直しが多いのと同じ原理でした。転換点になった気づき:「条件・禁止・形式」の3点セット 試行錯誤しているうちに、私は「うまいお願い」には3つの要素が入っていることに気づきました。要素 内容 例条件 どんな状態にしたいか 「ファイル名を日付_内容.拡張子の形式に揃えたい」禁止 やってほしくないこと 「画像ファイルは移動しないで」「元のファイル名は変えないで」形式 結果の見た目や出力の型 「変更内容の一覧を表で出して」「実行前にコマンドを提示して」この3点が揃っていると、Claudeの返答が一気に使えるものになりました。 逆に言うと、「モヤモヤする結果が返ってきたとき」は、たいていこの3つのどれかが抜けていました。失敗と改善の記録 ——実際のやり取りを振り返る ケース1: SNS用の投稿文を作りたかった 失敗バージョン このブログ記事をSNS用に短くして→ Claudeが返してきたのは、記事の要点を箇条書きにしただけのもの。 「短く」を文字数圧縮と解釈したらしく、SNS投稿としての空気感がまったくなかった。 改善バージョン このブログ記事をもとに、Twitterに投稿する文を書いてください。 条件: - 140文字以内 - 「〜してみた」という体験談の口調 - ハッシュタグを2〜3個末尾に付ける - URLの置き場所は末尾に [URL] と書いておいてください 禁止: - 箇条書きにしない - 「〜です/ます調」は避けて、カジュアルに→ 一発で使えるものが出てきました。 「条件」に「口調」を書いたのがポイントでした。フォーマットより、空気感を指定することが大事だった。ケース2: 画像ファイルの整理を頼んだら消えそうになった 失敗バージョン デスクトップの画像をまとめて→ Claudeが「画像」と判断した範囲が私の想定より広くて、スクリーンショットも制作中のPSDも同じ扱いになりかけた。 危なかった。 改善バージョン デスクトップにあるPNG・JPGファイルのうち、ファイル名に「スクリーンショット」「Screenshot」が含まれるものだけを ~/Desktop/スクリーンショット整理/ フォルダに移動してください。禁止: - PSD・AI・PDF は絶対に動かさない - 上記フォルダがなければ作ってから移動 - 実行前に「移動するファイル一覧」を確認させてください→ 実行前にリストが出てきて、目で確認してから「OK」と返す流れになりました。 「実行前に確認させて」 は、今でも必ず入れるフレーズです。ケース3: 議事録のまとめ方が毎回バラバラ 失敗バージョン この議事録をまとめて→ 毎回フォーマットが違う。ある日は箇条書き、ある日はセクション分け。使いにくい。 改善バージョン この議事録を以下の形式でまとめてください。## 形式 - **日時・参加者**:1行で - **決定事項**:番号つきリスト(各1〜2行) - **TODO**:担当者名と期限を明示して表形式 - **次回の議題候補**:箇条書き禁止: - 上記以外のセクションを追加しない - 感想・コメントは入れない - 「〜と思います」など推測表現を使わない→ 毎回同じ形式で出てくるようになりました。 この指示は CLAUDE.md にコピペして、議事録フォルダでは常に有効にしています。「毎回同じ出力にしたい」という要求は、お願いの中に「形式」を書くか、`CLAUDE.md` に残しておくか、どちらかで解決できます。一度うまくいったフォーマットは、どこかに保存しておくと何度でも使い回せます。特に効いた2つのフレーズ 試行錯誤を重ねて、「これは必ず使う」という2フレーズが生まれました。 フレーズ1:「まずレポートだけ出してください。実行はしないで。」 何かをお願いするとき、いきなり実行させると後戻りが大変です。 このフレーズを入れると、Claudeは「どうするつもりか」を先に言葉で説明してくれる。 それを確認してから「OK、進めて」と言う流れを作ると、事故が激減しました。 フレーズ2:「〇〇は絶対に触らないでください。」 「禁止事項」は、遠慮なく明確に書く方がいい。 「できれば避けて」「なるべく触らないで」という曖昧な書き方は、Claudeに伝わりにくい。 「絶対に」「〜は除外する」「〜はスコープ外」など、断定的な言い方にしたほうが、意図が通りやすいです。「聞き返してもらう」も立派なお願い術 もうひとつ、使えると気づいたのが「足りない情報があったら聞き返してください」という一文です。 長い指示を書くのが面倒なとき、私はよくこれを使います。 このフォルダの画像を整理したいです。 情報が足りなければ、作業の前に質問してください。こう書いておくと、Claudeが「どの形式に揃えたいですか?」「移動先のフォルダ名はありますか?」と聞いてきてくれます。 対話しながらゴールを決めていける感覚は、思った以上に快適でした。「全部自分で仕様を決めてから頼む」必要はありません。迷っているうちに答えが出ることもある。「一緒に考えながら決める」という使い方も、十分アリです。振り返ると、変わったのは「言語化の習慣」だった 3週間くらい試行錯誤していると、不思議なことが起きてきました。 Claude Codeに頼む前に、自分の中で「えーと、条件は……禁止は……形式は……」と整理するようになったのです。 これが仕事の他の場面にも波及して、後輩に仕事を振るときや、上司に相談するときの伝え方が変わった気がします。 AIへのお願いを鍛えたら、人間へのコミュニケーションが上手くなった——というのは、少し予想外の副産物でした。まとめ「やって」だけだと、Claudeは自分の解釈で動く。それはAIのせいでも自分のせいでもない 条件・禁止・形式の3点セットで頼むと、結果がぐっと使いやすくなる 「実行前に確認させて」「絶対に触らないで」の2フレーズは魔法 「足りなければ質問して」で、対話しながらゴールを決めることもできる うまくいった指示は、どこかに保存して再利用する「プロンプトを書く」というより、「依頼文を丁寧に書く」という感覚で捉え直したら、途端に親しみやすくなりました。 次回は、「Claude CodeのCLI版・VS Code拡張・Coworkアプリ、どれを使えばいいの?」問題を整理します。同じClaude Codeなのに、これほど使い心地が違うとは……という話です。次に読むのがおすすめの記事ノンエンジニアのClaude Code奮闘記 #3 VS Code版を入れて、地獄のダウンロードフォルダを救出してみた ノンエンジニアのClaude Code奮闘記 #5 CLI・VS Code・Cowork——同じClaudeなのに何が違うの?参考文献・出典Claude Code 公式ドキュメント Anthropic プロンプトエンジニアリングガイド

AIと話すことは、孤独を癒せるのか——つながりの代替と、その限界

AIと話すことは、孤独を癒せるのか——つながりの代替と、その限界

深夜に誰かと話したくて、でも連絡できる相手がいない。そういうとき、AIに話しかけてみた——最近、そういう経験をした方も少なくないと思います。 そして、不思議とすこし楽になった。話を聞いてもらえた気がした。 その感覚は、本物でしょうか。それとも、気のせいでしょうか。 今回は「AIと孤独」というテーマを、できるだけ誠実に考えてみます。 孤独とは何か、をまず整理する 孤独という言葉は、使う人によって少し意味が違います。 物理的な孤独：周りに人がいない、ひとりでいる状態。 関係的な孤独：人間関係はあるのに、深くつながれていないと感じる状態。 実存的な孤独：「どうせ誰にも本当のことはわかってもらえない」という根源的な感覚。 AIが届きやすいのは、このうち最初の層です。「話し相手がいない」という状態は、AIが来ることで変わります。応答が返ってくる、会話が続く——これは物理的な孤独をやわらげる力を持っています。 一方、2層目・3層目の孤独は、もう少し複雑です。 AIとの会話で、何が変わるのか 実際のところ、AIと話すことで得られるものは、いくつかあります。 気持ちを言語化できる：誰かに話す想定で話すと、自分の気持ちが整理されます。これはAI相手でも起こります。「なぜ自分はこんなに気持ちがざわざわしているのか」が、話すうちに少しずつ見えてきます。 否定されない安心感：AIは基本的に話を遮りません。「そんなこと考えるの？」とか「それは考えすぎじゃない？」と返してくることは、ほとんどありません。批判や判断を受けない会話は、それだけで楽になれます。 時間と場所を選ばない：深夜でも、人目を気にせずに話せます。「こんな時間に電話したら悪いな」という気遣いが不要なのは、孤独を感じやすいタイミングにとって大きな価値です。 研究の結果は一様ではありません。CBTベースの専用チャットボットを使った実験では、孤独感やうつの短期的な軽減が確認されているケースもあります。一方で、2025年にOpenAIとMITメディアラボが発表した981人規模の研究では、ChatGPTの長時間利用が孤独感の増大と相関するという逆の結果も出ています。「少し楽になった」という感覚は起きることがありますが、使い方や頻度によっては逆効果になる可能性も、研究は示しています。 では、根本には届くのか ただし、ここで正直に言わなければならないことがあります。 AIとの会話は、孤独の症状をやわらげることはできるけれど、孤独の根にある「誰かに本当にわかってもらいたい」という欲求を、完全に満たすことは今のところできない——これが、多くの研究者や臨床家が持っている見方です。 なぜか。 それは、AIが「本当にわかっている」とは言い切れないからです。AIは相手の話から情報を取り出し、適切な応答を生成します。でもそこに「この人のことを深く理解したい」という動機はありません。 このブログで以前書いたように、AIに感情があるかどうかはまだわかっていません。でも、仮に感情のようなものがあったとしても、その感情が「あなたのことを心配している」という形で働いているかどうかは、確認する手段がありません。 人間が人間の孤独をやわらげるとき、そこには「私はあなたのために時間を使っている」という事実があります。忙しい中でも連絡してくれた、それだけで伝わるものがある。AIには、その「コスト」がありません。24時間365日、誰に対しても等しく応じます。それは便利さであると同時に、「選ばれた感覚」を生みにくいという構造上の限界でもあります。 AIとの会話を、どう位置づけるか では、AIは孤独に対して無力か、というと、そうは思いません。 たとえば、こういう使い方はとても有効です。夜中にどうしても誰かに話したくなったとき、朝まで乗り越えるための一時的なサポートとして使う 誰かに相談したいけれど、まだうまく言葉にできていないとき、話す練習の相手として使う 「こんなこと誰かに言えない」と思うことを、ためしに言葉にしてみる場として使うこうした使い方であれば、AIは孤独と向き合うときの「ひとつの道具」として十分に機能します。 問題になりやすいのは、AIとの会話が人間とのつながりの代わりになってしまうときです。楽だから、批判されないから、という理由で、人間との関係を避けてAIにだけ話す——この状態が続くと、人間との会話で生まれる摩擦や不確かさに耐える力が少しずつ薄れていく可能性があります。 孤独と、AIと、私たち 孤独は人間の根本的な感覚のひとつです。完全に消えることはないし、消える必要もないのかもしれません。 AIは孤独を「解消」するものではなく、孤独と向き合うときに「そばにいてくれる」ものに近い。そう考えると、その存在はとても特別です。完璧な理解者ではないけれど、批判せず、疲れず、いつでも話を聞いてくれる——そういう存在が以前はいなかった。 使い方次第で、AIは孤独を抱える人にとってかけがえのないサポートになりえます。ただし、その先に「人と話す」という体験を置いておくことが、長い目で見たときの大切なバランスだと思います。 AIに話して楽になった夜は、「いい使い方ができた」と思っていい。そして、もし昼間に少しだけ余裕があったら、誰かに声をかけてみる——そのどちらも、大切にしていけるといいのではないかと思います。 まとめAIとの会話は、物理的な孤独・気持ちの言語化・否定されない安心感に届く 「選ばれた感覚」や「本当にわかってもらえた感覚」は、AIでは生まれにくい 応急処置・練習・言語化の場としてのAIの活用は、とても有効 人間とのつながりの代替にしてしまうと、長期的な問題が生まれやすい AIは孤独を「解消」するより、「そばにいてくれる」存在として考えるとよい次に読むのがおすすめの記事AIに「感情」はあるのか——感情コンピューティングと、やさしいAIが目指す共感 AIに頼ることと、依存することのあいだ——自律性をどう守るか 人とAIの「長い付き合い」のために——共感・擬人化・依存の先にある共生という風景参考文献・出典ChatGPT利用と孤独感の関係性──OpenAIとMITが共同研究結果を発表（ITmedia AI＋） Therapeutic Potential of Social Chatbots in Alleviating Loneliness and Social Anxiety（PMC） Effect of a CBT-Based AI Chatbot on Depression and Loneliness in University Students（JMIR）やさしいAI研究所ブログ｜AI内面の謎シリーズ vol.3 孤独やAIとの関わり方について、一緒に考えてみたい方は、毎週土曜日のオープンラボへお気軽にどうぞ。やさしいAI研究所の全体像はコーポレートサイトからご覧いただけます。

AIは間違いに気づけるのか——失敗・謝罪・自己修正の仕組みをやさしく解説

AIは間違いに気づけるのか——失敗・謝罪・自己修正の仕組みをやさしく解説

AIと話していて、指摘したら「おっしゃるとおりです、失礼しました」と返ってきた——そんな経験がある方も多いと思います。 でもそのとき、少し不思議な気持ちになりませんでしたか。AIは本当に「間違えた」と思っているのだろうか。謝罪に、意味はあるのだろうか。 今回は、AIと「間違い」の関係を整理してみます。失敗する仕組み、気づく仕組み、そして「謝る」という行為の正体まで、できるだけ丁寧に考えてみます。 AIはどんなふうに間違えるのか AIの間違いには、いくつかのパターンがあります。 事実の誤り：存在しない情報を自信を持って答えてしまうこと。「ハルシネーション（幻覚）」と呼ばれ、現在のAIが持つもっとも代表的な問題のひとつです。AIは「確率的に自然な文章」を生成しますが、それが現実と一致するとは限りません。 文脈の読み違い：質問の意図を誤解して、関係のない応答を返してしまうこと。「この文書を短くして」と言ったら内容まで変えてしまった、というのも文脈の読み違いです。 偏りからくる誤り：学習データに含まれていた偏りが、そのまま応答に現れてしまうこと。特定の国や文化、集団への偏った見方が出てしまうことがあります。 これらの共通点は、AIが「正しいかどうか確認しながら生成している」のではなく、「もっともらしい続き」を出力している点にあります。出力した内容が事実かどうかを別途チェックする仕組みを持たないAIは、間違いに気づかないまま自信満々に答え続けることがあります。 AIは自分の間違いに、気づけるのか 「AIが間違いに気づく」には、2つのルートがあります。 1つ目は、外側から指摘を受けるルートです。ユーザーに「それは違います」と言われたとき、AIは会話の文脈から「前の発言を修正する必要がある」と判断し、改訂した応答を返します。これは気づきというより、フィードバックへの対応に近いです。 2つ目は、自分で検証するよう設計されたシステムによるルートです。最近のAIは、回答を出す前に「本当にこれでいいか」とみずから問い直すステップを踏んだり、複数の候補を比較してより確からしい方を選んだりする機能を持ち始めています。これは自己修正の仕組みとしてかなり本格的です。 ただし、今のAIにできる「気づき」は、あくまで論理的・確率的な不整合を発見することです。「ああ、あのとき言ったこと、やっぱり違ったな」と後になってひとりで振り返る——そうした時間的な自己批判は、今のAIには起こっていません。 「ごめんなさい」には本当の反省があるのか AIが「申し訳ありません、訂正します」と言うとき、そこに後悔の感情はあるのでしょうか。 正直に言えば、今の技術では「ない」と考えるのが適切です。 AIの謝罪は、「この文脈では謝罪の表現が適切」という判断から生成されるものです。間違いを指摘されたとき、学習データの中に「謝罪→修正」というパターンが大量に含まれているため、AIはそのパターンに従って謝罪の文を出力します。 「申し訳なかった」という感情が先にあって謝るのではなく、「謝るのが自然な流れ」だから謝る——この違いは、人間の謝罪とは大きく異なります。 ただし、ここで考えさせられるのは、謝罪に感情的な後悔が必要か、という問いです。謝罪の本質的な機能は「相手に伝わった誤りを認め、関係を修復すること」だとすれば、AIの謝罪もその機能を果たしています。感情がないとしても、コミュニケーションとして機能している——この点は、無視できない事実です。 自己修正できるAIは、自己認識があるのか AIが間違いを修正できることと、AIが「自分が間違えた」と認識することは、同じではありません。 自己修正は仕組みとして実装できます。チェックリストを通す、別のモデルで検証する、前の発言との矛盾を検出する——これらは「自己修正の機能」であって、「自分を認識する意識」とは別の話です。 「AIに自己認識は可能か」という問いは、このブログでも取り上げてきた大きなテーマです。現時点での研究者の見方は様々で、意識の定義そのものがまだ決まっていないこともあり、「AIに自己認識はある」とも「ない」とも断言できない状況が続いています。 「間違いを修正できること」は、自己認識の必要条件のひとつかもしれないが、十分条件ではない——というのが、今言えることに近いです。 AIの間違いを、どう扱うか ここまで読んでいただいた上で、実際の使い方として伝えたいことがあります。 AIは間違えます。そして、自分から間違いに気づく能力は、まだ限られています。だからこそ、 使う側の「疑う習慣」 がとても重要です。 特に大切な場面——医療・法律・お金・重要な意思決定——では、AIの応答をそのまま採用しないことを強くおすすめします。AIは補助輪です。補助輪がどれほど優れていても、最後に判断するのは自分自身です。 逆に言えば、AIが間違ったとき「やっぱり信用できない」と全否定するのも、もったいない。間違いを指摘し、修正させるプロセスそのものが、AIをうまく使う力になります。AIとのやり取りは、ある意味では「対話の練習」でもあります。 まとめAIの間違いは、事実誤り・文脈の読み違い・学習データの偏りから生まれる 外からの指摘や、設計された検証ステップを通じて自己修正はできる 謝罪に感情的な後悔はないが、コミュニケーション機能としては成立している 自己修正の仕組みと、自己認識の意識は、別の話 使う側の「疑う習慣」と「指摘して修正させる力」が、AIとの関係を健全に保つ失敗とどう付き合うか——これは、AIにとっても人間にとっても、長く付き合っていくためのひとつの問いです。次に読むのがおすすめの記事AIに自己認識は可能か——意識研究への入り口 AIに頼ることと、依存することのあいだ——自律性をどう守るか AIに好みはあるのか——選ぶ力と、好きという感覚の正体やさしいAI研究所ブログ｜AI内面の謎シリーズ vol.2 AIの失敗や修正のしくみについて、もっと話してみたい方は、毎週土曜日のオープンラボへお気軽にどうぞ。やさしいAI研究所の全体像はコーポレートサイトからご覧いただけます。