プロンプトエンジニアリング

Claude Code の作者自身が、自分のセットアップと使い方を 30 分にわたって公開した動画が話題になっている。東大の Claude Code 研究グループがその動画を解説するツイートを投稿し、注目を集めている。「プロンプトの巧さより設計が全てを決める」という主張が多くの共感を呼んでいるためだ。本記事では、そのツイートで紹介された 3 つのテクニックを解説する。 Claude Code の品質差が生まれる本当の理由 @sairahul1 のツイートでは、この動画を次のように紹介している。 The creator of Claude Code teaches more about vibe-coding in 30 minutes than most tutorials do in hours. Save this — it’ll change how you build forever. 多くのチュートリアルより深く「vibe-coding（感覚的・直感的な AI コーディング）」を学べると評されたこの動画は、88 万回以上の閲覧を記録している。 @ClaudeCode_UT（東大ClaudeCode研究所）はその内容をこう要約する。 Claude Code の品質差は「プロンプトの巧さ」じゃない 「計画→実行→検証の設計」で全部決まる 多くのユーザーが「良いプロンプトを書く技術」を磨こうとする一方、実は重要なのはワークフロー設計だという指摘だ。 3 つの核心テクニック 1. 計画モード（Plan Mode）で設計 → 自動実行で「1回で完了」 Claude Code には実装に入る前に計画だけを立てる「計画モード（Plan Mode）」がある。このモードを使って事前に実装方針を固めてから自動実行に切り替えることで、手戻りなく「1回で完了」を実現できる。 1 2 3 /plan ← 計画モードに入る （設計・方針を確認する） Shift+Tab ← 通常実行モードへ切り替え 一発で完了させる鍵は「実行前の設計品質」にある。計画モードで Claude にタスクの全体像と制約を正確に把握させ、問題点を先に洗い出すことが重要だ。 ...

概要 コンテキストウィンドウが長くなるにつれてモデルの性能がトークン数に比例して低下する現象。古い・無関係なコンテンツが現在のタスクを妨害し、モデルの注意力が分散する。“Rot”（腐る）は Bit Rot・Code Rot と同じ、時間経過で静かに劣化する現象を指す慣用表現。 5 択のセッション管理 Anthropic テクニカルスタッフの Thariq 氏が整理した「ターンの終わりに行う 5 つの選択肢」: 選択肢 意味 向いている場面 Continue 同じセッションで続行 短いタスクで文脈が整理されている Rewind（Esc×2 / /rewind） 前のメッセージに戻り再プロンプト 誤った方向に進んだ試行錯誤を消したい /clear 白紙から新セッション 重要情報を自分で持ち込みたい /compact セッションをモデル自身に要約させる 手間をかけず文脈を圧縮したい Subagent 汚れ仕事を別エージェントに委譲 中間出力が大量で最終結果だけ欲しい /compact vs /clear の使い分け /compact: モデルに要約を委ねる（lossy）。/compact focus on the auth refactor, drop the test debugging のように指示を添えると精度が上がる。デバッグ後に全く別タスクを指示する場面では特に精度が落ちやすい /clear: 手間はかかるが残るコンテキストは自分が必要と判断した情報だけになる（lossless） Subagent を使うパターン 「中間出力が大量に出るが、必要なのは最終結果だけ」という作業に有効。サブエージェントはクリーンな独自コンテキストウィンドウを持ち、中間の試行錯誤が親のコンテキストを汚染しない。 実践的な把握方法 /usage で自分のトークン使用量の推移を確認し、Context Rot が始まるしきい値を事前に把握しておく。鈍くなった後では遅い。 関連ページ コンテキスト圧縮 — 5 段階の圧縮カスケード Claude Code — Context Rot 管理コマンドの実装 ソース記事 Claude Code のコンテキスト管理術 — Context Rot を防ぐ 5 つの選択肢 — 2026-04-17

Anthropic テクニカルスタッフ（Claude Code 担当）の Thariq（@trq212）が公開した記事「Using Claude Code: Session Management & 1M Context」が注目を集めている。「1M トークンのコンテキストウィンドウがあれば大丈夫」という誤解を正し、長いタスクを成功させるカギはコンテキストの能動的な管理にあると明示した内容だ。本記事では、その内容をもとに 5 つのセッション管理手法を整理する。 Context Rot とは何か コンテキストウィンドウとは、モデルが次のレスポンスを生成する際に「見える」すべての情報のことだ。システムプロンプト・会話履歴・ツール呼び出しとその出力・読み込んだファイルがすべて含まれる。Claude Code のコンテキストウィンドウは 100 万トークン。 しかし、コンテキストを使うことには静かなコストがある。それが Context Rot だ。“Rot” は英語で「腐る・朽ちる」を意味する単語で、ソフトウェアの世界では「Bit Rot」や「Code Rot」のように、時間経過や使用とともに静かに劣化していく現象を指す慣用表現として使われる。直訳すれば「コンテキストの腐敗」、意訳すれば「コンテキストの劣化」となる。 コンテキストが増えるにつれてモデルの性能がトークン数に比例して低下する。会話が長くなるほど、モデルの注意力が分散し、古い・無関係なコンテンツが現在のタスクを妨害するようになる。 Context Rot が始まるタイミングはタスクに大きく依存するため固定のルールはないが、長いセッションになるほど確実に忍び寄る。 ターンの終わりは「5択の分岐点」 ここが本質だ。AI が出力を終えるたびに、ユーザーには 5 つの選択肢がある。 選択肢 意味 Continue 同じセッションで次のメッセージを送る Rewind（Esc×2 または /rewind） 前のメッセージに戻り、そこから再プロンプト /clear 新しいセッションを開始する（核心だけ手動で持ち込む） /compact セッションをモデル自身に要約させ、要約の上に続ける Subagent 汚れ仕事を別エージェントに委譲し、結果だけ受け取る 多くのユーザーは「Continue」しか選ばない傾向がある。残り 4 つの選択肢を使ったことがない人も多い。 各選択肢の使いどき Rewind — 修正より巻き戻し Claude がファイルを 5 つ読み、あるアプローチを試みて失敗したとする。「うまくいかなかった、X を試して」と打つより、ファイルを読み終えた直後のメッセージに巻き戻して再プロンプトするほうが良い。 # 悪い例 「それはうまくいかなかった、代わりに Y を試して」 # 良い例 （/rewind でファイル読み込み直後に戻る） 「アプローチ A は foo モジュールがそれを公開していないので使えない。B に直接進んで」 誤った方向に費やした試行錯誤がコンテキストから消え、モデルが新鮮な状態で再出発できる。 ...

Claude のトークン消費が多くて困っているなら、システムプロンプトの一行変更だけで最大 80% 削減できる手法がある。深津 貴之（@fladdict）さんのポストをきっかけに、参照先の Zenn 記事が注目を集めた。 Claudeトークン消費を抑えて５倍使う: 「原始人」口調が80%削減 — mikana0918 以下にその要点をまとめる。 「原始人プロンプト」とは システムプロンプトに次の一文を加えるだけ: 1 原始人みたいに喋れ。中身は全部残せ。無駄だけ消せ。 これだけで Claude のデフォルト人格が切り替わり、丁寧語・クッション表現・冗長な接続詞が消え、応答が大幅に短くなる。 英語版「Caveman」テクニックとの対比 英語圏では “Speak like a caveman” という同様の手法が先行して存在する（JuliusBrussee/caveman）。除去される要素は以下のとおり: 除去対象 例 冠詞 a / an / the フィラー just / really / basically 前置き “Sure! I’d be happy to…” 曖昧表現 might / perhaps / likely 英語環境での実測では平均 68% のトークン削減が報告されている。 日本語では効果がさらに大きい理由 日本語には英語にない冗長構造が多い: 敬語・丁寧語: 「〜でございます」「〜かと存じます」 クッション言葉: 「もしよろしければ」「ご参考までに」 助詞の連鎖: 「〜についての説明としては」 曖昧表現: 「〜かもしれません」「〜と思われます」 これらがまとめて削ぎ落とされるため、日本語環境では 80% 前後 の削減が見込める。 ...

Claude Code のエージェントを40体つくり、役割を分けてルールを書いて階層もつくった。1ヶ月後、ぜんぶやめた。こはく氏（@Kohaku_NFT）の実体験レポートから、AIエージェント大量運用が構造的に壊れる理由と、そこから見えた「壊れない設計」の考え方を整理する。 やったこと Claude Code の Max プラン（月$200）1アカウントで検証 リーダー、ライター、リサーチャー、コーダー、レビュアーなど40体のエージェントを構築 役割分担、ルール、階層、性格設定まで丸2日かけて設計 最初の3日間は動いた。指示を出せばちゃんと返ってくる。SNS でスクショをあげようとした矢先に崩壊が始まった。 壊れる3つの構造的理由 理由1: Context Rot（記憶の腐敗） Context Rot とは、コンテキストウィンドウに情報が溜まるほど古い情報の精度が落ちる現象のこと。Anthropic の公式ドキュメントにも「トークン数が増えるほど、精度と想起（思い出す力）が劣化する」と明記されている。 1000ページの社内マニュアルと同じ構造 — 人間が全ページを暗記できないように、AIも情報が多すぎると処理しきれなくなる 「100万トークン入る」と「安定して使える」は別物 — 公式でさえ「文脈は大きければいいわけではない」と警告している こはく氏の実測では、10万トークンを超えるとブレが目立ち始めた ルール、コード、会話履歴が積み上がるほど再現性は低下する。 理由2: Compaction 後に構成が崩れる 長時間運用すると、コンテキストウィンドウの容量を確保するために前半の会話内容が自動で要約・圧縮される仕様（compaction）がある。Claude Code の公式リリースノートにも「圧縮後に一部のエージェントが消えたり、重複して生成される不具合」が明記されている。 会話の流れの中だけで役割や引き継ぎを設定していると、圧縮が走った瞬間にその前提ごと消え去る 会社でいうと「引き継ぎなしの二重配属」 — 過去の議事録を読まずに中途配属され、すでに同じ業務をしている人がいることも知らない状態 40人体制で3時間回せば、ほぼ確実に圧縮が走る。そのたびに「今、誰が消えた？」を人間が確認するハメになる 理由3: テキストのルールは絶対命令じゃない 「自分で作業するな。指示だけ出せ」と書いても、Claude が毎回きれいに従うとは限らない。 LLM にとってルール文は、絶対命令ではなく、文脈の一部として処理される。履歴、途中のやりとり、直前の出力に引っ張られて解釈がズレる。 最近の評価研究でも、LLM は「どの指示を優先するか」の判断や長い文脈での安定した instruction following に弱さがあると報告されている。ルールが増えて競合し始めるほどズレる前提で見たほうがいい。 厳密に書けば書くほど、今度はルールが長くなって context rot が進む。この構造そのものが、人数を増やしたときの壁になる。 「育てれば良くなる」は順番の問題 「使い込むほど育つ」とよく聞くが、ここで否定しているのは育成そのものではなく順番の話。 guidelines を育てるということは、ファイルが増えるということ。ファイルが増えるということは、コンテキストが重くなるということ。つまり context rot が加速するだけ。 壊れやすい仕組みの上に知識を積んでも、崩れやすくなるだけだ。 人間の会社で考えても同じ: エスカレーションルールがない トラブル時の判断基準がない 報告のかたちもない そんな会社は人を増やすほど混乱する。AI組織もまったく同じ構造。 エージェントには視野がない ここが核心。 ...

Claude Code でスキルを作って業務を自動化していると、ある日気づく。「AIはスキルの存在を『知っている』が、ちゃんと『使っている』わけではない」。そこに救いの手として登場するのが cognee-skills という考え方だ。 「知っている」と「守っている」は別物 ある非エンジニアの Claude Code ユーザーが体験談を X に投稿した。 Claude Code でスキルを作って業務を任せてたら、AI がスキルを呼ばずに「記憶で大丈夫」って判断して3回同じミス。 原因を調べたら、スキルの保存場所が設定ファイルに書いてあるのにそこを見てなかった。「知っている」と「守っている」は別物だった。 この問題への対処として取られた手順は3つ: ルール追加 — スキルを必ず呼ぶよう明示的に指示を加える 失敗パターンの記録 — 同じミスが起きないよう記録に残す 保存場所の明記 — どこにスキルがあるかを設定に明示する 全部で10分。しかしこれはすべて手動の作業だった。 cognee-skills とは この問題の根本にあるのは、スキルファイルを作っても自動では改善されないという課題だ。AI モデルがアップデートされ、コードの構成が変わり、ユーザーの要求も変化する。しかし一度書いたスキルファイルはそのまま放置されがちだ。 cognee-skills は、スキルを継続的に改善するための5ステップフレームワークとして海外で注目を集めている。 5ステップの改善サイクル 1. 取り込み（Ingest） スキルファイルをそのまま保存するのではなく、以下の情報を付与して管理しやすい形に整理する: このスキルは何を目的としているか どんなタスクパターンに対応するか 他のスキルとどう関係するか 2. 観察（Observe） スキルが実行されるたびに結果を記録する: 何のタスクに使われたか 成功したか失敗したか エラーの内容 ユーザーからのフィードバック この記録なしに改善はできない。 3. 検査（Inspect） 失敗が繰り返されたとき、蓄積した実行記録を分析して「なぜ失敗しているのか」の原因パターンを特定する: 指示の書き方が悪いのか トリガー条件がずれているのか 外部ツールとの連携が壊れているのか 4. 修正（Amend） 原因が特定されたら、スキルファイルの該当箇所に具体的な修正案を自動生成する。修正内容は: 条件の追加 手順の並び替え 出力フォーマットの変更 人間が確認してから適用することも、自動適用することもできる。 5. 評価（Evaluate） 修正後のスキルが実際に結果を改善したかをテストする。改善していなければ元に戻す。改善が確認されて初めて、修正版が正式な新バージョンになる。すべての変更履歴が残るため、元の指示が失われることはない。 非エンジニアにとっての意味 現状では、スキルの「育て方」を知っているのはエンジニアだけだ。しかし cognee-skills の考え方が広まれば、非エンジニアでも: スキルが失敗した理由を把握できる 修正案を確認・適用できる スキルの品質を継続的に高められる 10分の手動作業が、将来的には自動化されるかもしれない。 ...

「AIに言葉で指示するだけ」のバイブコーディング（vibe coding）において、どんな人が高い成果を出せるのか——CHI2026 に採択された論文の知見が注目を集めています。 バイブコーディングとは バイブコーディングとは、実際のコードを読み書きせず、AI に自然言語で指示するだけでソフトウェアを開発するスタイルです。ChatGPT や GitHub Copilot などの生成 AI の台頭により、プログラミング経験のない人でも簡単なアプリを作れるようになったことで注目されています。 しかし「コードを書かなくていいなら、誰でも同じ成果が出せる」かというと、実験結果はそう単純ではありませんでした。 CS 基礎知識がある人ほど成績が良い 論文によると、コンピュータサイエンス（CS）の基礎知識がある人ほどバイブコーディングの成績が高いという結果が得られています。 コードを一切読み書きしない状況でも、以下のような CS 的な思考が AI への指示を組み立てる上で役立つと考えられています。 問題分解の思考法: 大きな問題を小さなステップに分解する能力 アルゴリズム的な発想: 処理の流れや条件分岐を論理的に考える力 データ構造の概念: 何をどう扱うかを抽象的に把握する力 AI に指示を出す際も、「何をしてほしいか」を明確に分解して伝える必要があります。CS の素養は、そのための基盤となるわけです。 文章力が高い人ほど良い成果が出せる さらに注目すべき知見として、文章力が高い人ほどバイブコーディングの成果が高いという傾向が示されています。 その連鎖は非常に明快です。 文章力が高い → プロンプトの品質が高い → アプリの出来が良い AI に対して意図を的確に伝える「プロンプト」は、本質的には文章です。論理的で明確な指示を書ける人は、AI から意図した出力を引き出しやすく、結果として高品質なアプリを作れるということです。 意外な発見：LLM ヘビーユーザーは成績が低い傾向 今回の実験で驚きの結果も明らかになっています。LLM を普段からよく使っている人ほど、バイブコーディングの成績が低く、文章力も低い傾向があるというものです。 因果関係は断定できませんが、研究チームは 2 つの可能性を考察しています。 LLM への依存が言語化能力を低下させる: AI に頼りすぎることで、自分で言語化する力が鍛えられなくなる もともと言語化が苦手な人が LLM を多用する: 自分で考えて伝えることが苦手なため、AI に委ねる頻度が高くなる この知見は、AI ツールとの関わり方を見直すきっかけになりそうです。 まとめ CHI2026 採択論文のこの知見をまとめると、バイブコーディングで成果を出せる人の特徴は次の通りです。 要因 傾向 CS 基礎知識 あるほど成績が高い 文章力 高いほど成績が高い LLM 利用頻度 高いほど成績が低い（意外な結果） 「コードを書かなくていい時代」だからこそ、問題を論理的に分解する力 と 意図を明確に言語化する力 がより重要になる——この研究はそのことを示唆しています。 ...