3ヶ月後、誰かにシンプルな質問をされる。そしてあなたは1時間かけて、かつて一度読んだあの1段落を探し回ることになります。

書類はある。知識はそこにある。でも散らばっていて、バラバラで、探せない。

知識労働者なら誰でも経験する「知識の迷子」状態です。

私はこの問題の解決策を見つけました。Andrej Karpathyの1ページのアイデア文書、AIコードエディタのCursor、無料のノートアプリObsidianを組み合わせたものです。そのアイデアから完全に動作するナレッジベースを作るまで約30分。どんなドキュメントを放り込んでも、構造化されたWikiページに変換し続けてくれます。

しかも私は、Wikiページを1ページも自分で書いていません。

Andrej KarpathyとはどんなAI研究者か

Karpathyの名前を知らなくても、彼がシェアしたものはAIコミュニティですぐ拡散します。OpenAIの創業メンバーで、テスラではAI・自動運転ビジョンチームを率いた人物で、技術の深い話を誰でもわかる言葉で説明することで知られています。私も彼のYouTubeの動画でお世話になっています。

最近、llm-wiki.mdという短いドキュメントを公開しました。製品でもアプリでもない。ただのアイデア文書です。AIエージェントを使ってパーソナルナレッジベースを構築・維持するパターンを、プレーンなMarkdownで書いたものです。

どんなAIエージェント（Claude、ChatGPT、Codexなど）にも貼り付けて使えるように設計されています。エージェントがそれを読んで仕組みを理解し、あなたのニーズに合わせた実装を作り上げます。

この1ページのアイデアが、今から紹介するものの全てのベースです。

普通のAIツールとLLM Wikiは何が違うのか

普通のAIツールはこう動きます。ドキュメントをアップロードして質問する。AIがファイルを検索して回答を生成する。これで十分機能しますが、AIは質問のたびに全てを忘れます。次の質問では最初から始まります。再読して、再検索して、再推論する。何も保存されない。何も積み上がらない。

LLM Wikiはこれを逆転させます。

AIが生のドキュメントを一度読んで、そこから構造化されたWikiを構築します。そのWikiはMarkdownファイルの集合体で、サマリーページ・製品ページ・概念ページ・用語集・比較表が全てWikiスタイルのリンクで繋がっています。新しいドキュメントを追加しても、最初からやり直しません。新しいソースを読んで、既存のWikiを更新し、必要な場所に追加し、矛盾を検出し、整合性を保ちます。

Wikiが積み上がり続ける成果物として機能します。使えば使うほど豊かになり、繋がりが増えていきます。

3つの層と3つの操作

LLM Wikiは3つのパーツから成り立っています。

raw/はあなたのドキュメントを置く場所です。PDF、Markdownファイル、クリップした記事、議事録、何でも構いません。AIはここから読み込むだけで、内容を変更しません。元データは手つかずのまま残ります。

wiki/はAIが全て作成・管理します。ページを構築し、クロスリファレンスを維持し、用語集を整備し、索引を更新します。あなたはブラウズするだけ。AIが書きます。

CLAUDE.mdは普通のAIをWiki専任の管理者として動かすための指示書です。どのページ種別が存在するか、新しいソースを処理するワークフロー、ページのフォーマット、問題チェックのタイミングが全て書かれています。

3つの操作も押さえておきます。

Ingest（投入） はドキュメントをraw/に置いてAIに処理を頼む操作です。AIはそれを読み込み、サマリーページを作成し、Wiki全体のエンティティページを更新し、新しい用語を用語集に追加し、索引を更新し、何をしたかをログに記録します。ソース1本で10〜15のWikiページに触れることもあります。

Query（質問） はWikiに問いかけます。AIは生のファイルではなくWikiを読んで回答します。役立つ回答はAnalysisページとしてWikiに保存できるので、質問すればするほどナレッジベースが豊かになります。

Lint（ヘルスチェック） はWikiの状態を確認します。矛盾、古い情報、リンクのない孤立ページ、欠けているクロスリファレンスを検出します。ナレッジベースのスペルチェックのようなものです。

CursorでのLLM Wiki構築：3つのプロンプトで全て終わった

実際に何が起きたかをそのまま書きます。

Cursorを開き、KarpathyのLLM Wiki原文を空のプロジェクトフォルダに入れ、AIに話しかけました。

プロンプト1

これは何ですか？テクニカルライターとして、どのように活用できますか？

Cursorはドキュメント全体を読んで、アイデアを私のロールにマッピングしました。

プロンプト2

計画を立てて、作成してください

たった5語です。Cursorはこのひとつのプロンプトでプロジェクトをまるごとプランして構築しました。raw/とwiki/フォルダの作成、エンティティ種別・ページフォーマット・9ステップのIngestワークフロー・Queryワークフロー・Lintワークフロー・セッション開始チェックリストを含むCLAUDE.mdの作成、そして4つのスターターWikiページ（index.md、log.md、overview.md、glossary.md）の作成まで、一気通貫で終わりました。

プロンプト3

Obsidianをセットアップしてください

CursorはHomebrewでObsidianをインストールし、Vaultを設定しました。新しいファイルはデフォルトでwiki/に保存、グラフビューはページ種別ごとに色分け、グラフビュー・検索・クイック切替のキーボードショートカットも設定済みです。

左にCursor（AIとの対話）、右にObsidian（リアルタイムでWikiをブラウズ）の2画面体制が完成しました。

ファイル構造と実際の使い方

リポジトリをクローンすると、次のような構成になります。

project-root/
│
├── llm-wiki.md # Karpathyの原文アイデア文書
├── CLAUDE.md # スキーマ（Wikiの動かし方をAIに伝える）
│
├── raw/ # ソースドキュメント（AIは読む、書かない）
│ └── .gitkeep
│
├── wiki/ # AIが生成するナレッジベース
│ ├── index.md # 全ページのカタログ
│ ├── log.md # いつ何が起きたかの記録
│ ├── overview.md # 全体像のサマリー（時間とともに進化）
│ ├── glossary.md # 用語、定義、スタイルルール
│ └── sources/ # rawドキュメント1本につき1サマリー
│
└── .obsidian/ # 設定済みのObsidian Vault

この構造が機能する理由は、責任の分離が明確だからです。raw/はあなたのもの。wiki/はAIのもの。あなたはwiki/に書かない。AIはraw/を変えない。

Step 1: クローンする

git clone https://github.com/balukosuri/llm-wiki-karpathy
cd llm-wiki

Step 2: Cursorで開く

プロジェクトフォルダをCursorで開きます。AIはCLAUDE.mdを自動で読んで、Wikiの構造とルール全てを把握します。別のAIエージェント（Claude Code、Codexなど）を使う場合は、CLAUDE.mdの内容をエージェントのコンテキストに貼り付けます。

Step 3: Obsidianで開く

同じフォルダをObsidian Vaultとして開きます。Obsidianが入っていない場合は、Cursorにこう聞けばいいです。

Obsidianを私のためにセットアップしてください

インストールからVault設定まで全てやってくれます。

Step 4: raw/にソースを投入する

何でも構いません。製品仕様書やデザインドキュメント、ミーティングの議事録、クリップしたウェブ記事、スタイルガイド、PDFレポート、テキストとして保存したメールスレッド、受け付けます。

Step 5: 「投入して」と指示する

Cursorでこう打ちます。

raw/my-document.pdfを投入してください

AIはこの順番で作業します。

1. ドキュメントを読む
2. 主要なポイントについて話し合う
3. wiki/sources/ にソースサマリーページを作成
4. 見つけた製品・機能・ペルソナ・概念のページを新規作成
5. 用語集を新しい用語で更新
6. 索引を全新ページで更新
7. 全体像が変わった場合は overview を更新
8. タイムスタンプ付きで wiki/log.md に全てを記録

Obsidianでページがリアルタイムに出現するのを見ると、初めてのときは少し驚きます。

Step 6: 質問する

全ソースで特定されている主なリスクは何ですか？

AIはWikiを読んで回答をまとめ、「これをWikiページとして保存しますか？」と聞いてきます。「はい」と答えると、その回答がWikiの恒久的なAnalysisページになります。質問がナレッジベースを豊かにする仕組みです。

Step 7: 使い続ける

ソースを追加するたびに、それまでの知識の上に積み上がっていきます。Overviewページが進化します。用語集が育ちます。クロスリファレンスが増えます。10〜15本のソースを投入すると、今まで気づいていなかったつながりをWikiが示してくれるようになります。

Step 8: ときどきLintをかける

10回Ingestするごとに一度くらい、こう打ちます。

Wikiをリントしてください

AIはページ間の矛盾、新しいソースで置き換えられた古い主張、リンクのない孤立ページ、言及されているのにページがない重要な概念、ページをまたいで不統一な用語を確認します。見つけた問題を報告し、どの修正を適用するか聞いてきます。

実際に使ってわかったこと

使い始めて気づいた、効果に差が出るポイントをまとめます。

ソースは1本ずつ投入する

まとめて複数のドキュメントをIngestすることもできますが、AIをガイドする機会を失います。サマリーを読んで、何を強調するかを伝えて、Ingest中に追加質問をする。あなたが関与するほどWikiは良くなります。

良い質問は保存する

質問して有用な回答を得たら、それをAnalysisページとして保存するようAIに指示してください。あなたの探索はWikiに蓄積されるべきで、チャット履歴の中に消えてはいけません。

グラフビューを使う

ObsidianでCmd+Gを押してみてください。どのページがハブで、どれが孤立していて、全体がどう繋がっているかを視覚的に確認できます。Wikiの成長を実感できる方法として、私はこれが一番好きです。

スキーマは自分用に書き換える

CLAUDE.mdは変更禁止ではありません。自分のドメインに新しいページ種別が必要なら（「APIエンドポイント」「顧客セグメント」「レシピのバリエーション」など）、スキーマに追加してAIに伝えてください。Wikiはあなたのニーズに合わせて変わります。

書く前に必ず用語集を確認する

何か書く前にwiki/glossary.mdを開きます。正しい用語、使ってはいけない用語、各選択の理由が全部あります。全部を頭に入れておかなくても、文章の一貫性が保てます。

自分でWikiページを書かない

この誘惑には負けないでください。あなたの仕事は良いソースを探して、良い質問をすること。AIの仕事はサマリー・クロスリファレンス・ファイリング・記録管理です。

なぜwikiは続かないのか、そしてAIが変えること

Wikiが廃れる理由は、知識へのこだわりが消えるからではありません。メンテナンスが重くなるからです。

クロスリファレンスの更新。サマリーの最新化。7ページ目と23ページ目が矛盾しないかの確認。用語集への新用語追加。新しいページと古いページのリンク設定。この作業は退屈で、繰り返しで、終わりがありません。だからWikiは古くなる。誰も信用しなくなる。やがて誰も開かなくなる。

AIはこの方程式を変えます。

AIはメンテナンスに疲れません。一度のパスで15ファイルを更新できます。新しい情報が古い主張と矛盾するときに検出します。用語集を最新に保ち、索引を完全に保ち、クロスリファレンスを整備し続けます。Wikiのメンテナンスコストがほぼゼロになります。

Karpathyは原文の中で、このアイデアが1945年のVannevar BushのMemexに関連すると述べています。文書を繋ぐ「連想の道筋」を持つパーソナルな知識ストアのビジョンです。私たちが作ったウェブはそれとは似ていません。公開で、ノイズが多く、文書間の繋がりはほとんど偶発的です。Bushのビジョンはプライベートで、キュレーションされ、深くパーソナルなものでした。LLM WikiはBushが想像したものに、過去80年間で作られたどんなものよりも近いと思います。Bushが解決できなかった部分は「誰がメンテナンスをするか」でした。今、その答えが出ました。

知識ベースの難しさは、読むことでも考えることでもありませんでした。ずっと、記録の維持だったのです。そしてそれはAIが最も得意とすることです。

TL;DR

• 問題：書類はある。でも知識がどこにあるかわからない。毎回一から探し直している。
• LLM Wiki：AIがドキュメントを一度読んで、構造化されたWikiを構築・維持し続ける仕組み。RAWフォルダ（あなたのドキュメント）→ スキーマ（CLAUDE.md）→ Wikiフォルダ（AIが書く）の3層構造。
• 操作は3つ：Ingest（投入→自動更新）、Query（質問→回答をページ保存）、Lint（矛盾・孤立ページ検出）。
• 構築は30分：Cursorで「これは何か」「計画して作成」「Obsidianをセットアップ」の3プロンプトだけ。
• 続く理由：AIはメンテナンスに疲れない。クロスリファレンス更新も矛盾検出も用語集維持も全部AIの仕事。
• あなたの仕事：良いソースを探すことと、良い質問をすること。それだけ。

投稿 AIが自動でメンテナンスし続けるナレッジベースをCursorで30分で作った は パイソンエンジニア部 に最初に表示されました。

「賢いモデルを使えば精度は上がる。でも、コストが跳ね上がる。」

Opusをフルで動かすと1タスクあたりの費用がかさむ。だからといってHaikuやSonnetだけで回すと、複雑な判断の場面で詰まる。ずっとどちらかを選ぶしかないと思っていませんでしたか？

Anthropicが2026年3月にリリースしたAdvisor Toolは、この二択を崩します。

安いモデルが実行を担い、判断が難しい局面でだけOpusに相談する。BrowseCompというベンチマークでは、Haikuのスコアが19.7%から41.2%へ2倍以上に跳ね上がりました。しかもコストはSonnet単体より安い。

この発想はどこから来たのか

Advisor Toolの背景には、UC Berkeleyの研究チームが2025年10月に発表した論文があります。タイトルは “How to Train Your Advisor: Steering Black-Box LLMs with ADVISOR MODELS”。

この論文が指摘した問題はシンプルです。

GPT-5やClaudeのような最先端モデルは、APIとして使う限り「ブラックボックス」です。重みを書き換えたりファインチューニングしたりはできない。カスタマイズの手段はプロンプトだけ。ところが、固定されたプロンプトには構造的な限界があります——入力が変わっても対応を変えられないし、コンテキスト長にも上限がある。

UC Berkeleyの研究者が提案した解決策は次のものです。

小さなオープンウェイトモデルを訓練して、大きなブラックボックスモデルに向けて「動的なアドバイス」を生成させる。

アドバイスは自然言語です。タスクの内容に応じて毎回カスタムの指示を生成し、モデルの出力を誘導します。

• GPT-5のRuleArena（税務申告ベンチマーク）スコアが71%改善
• Gemini 3 ProのSWEエージェントタスクのステップ数が24.6%削減
• 静的プロンプトオプティマイザ（40〜60%）に対して85〜100%で上回る

GPT-4o miniのような安価なモデルで訓練したAdvisorが、GPT-5のような最先端モデルにも改善効果を転移できました。GPTで訓練したAdvisorがClaudeにも効いた、という結果も出ています。

アドバイスが自然言語だから、特定のモデルに縛られずに汎化する、これが理由です。この研究が実証したことを、AnthropicがAPIとして実装したのがClaude Advisor Toolです。

Advisorは「考える役」、Executorは「動く役」

Advisor Toolの設計は、一般的なマルチモデル構成とは発想が逆です。

よくある設計では、大きなモデルがオーケストレーターとして全体を指示し、小さなモデルが作業をこなします。大きいモデルが「頭脳」で、小さいモデルが「手足」。

Advisor Toolは逆です。

SonnetかHaikuがExecutor（実行者）として、タスクをエンドツーエンドで担います。ツールを呼び、結果を読み、次のアクションを決める。すべてExecutorの仕事です。

Executorが自分では判断できない局面に来たとき、初めてAdvisor（Opusなど）に相談します。

OpusはExecutorの持つすべての情報を確認します。システムプロンプト、ツール定義、それまでの会話履歴、ツール結果——全部です。そのうえで、次の3つのうちいずれかを返します。

• このあとの進め方のプラン
• 現在のアプローチへの修正指示
• タスク完了のストップシグナル

Advisorは、ユーザーに見えるアウトプットを一切出しません。ツールも呼びません。ただExecutorにアドバイスを返して、Executorに戻す。それだけです。だから安い。

Opusが生成するのは、1回のアドバイスにつき400〜700トークンの短い指示文です。膨大なアウトプットを生成するのはSonnetかHaikuの仕事。Opusには「判断だけ」してもらう。Opusに全部任せるより格段に安く、Haiku単体より格段に賢い、このトレードオフが実現します。

なぜアドバイスがモデルをまたいで転移するのか

GPT-4o miniで訓練したAdvisorがGPT-5にも効き、GPTで訓練したAdvisorがClaudeにも効きます。アドバイスが自然言語だからです。特定のモデルアーキテクチャに依存しない。「どう進めるべきか」という自然言語の指示は、どのモデルでも理解できます。

研究者はこれを「learning to adviseはプロンプトエンジニアリングを静的な探索問題から、インスタンスごとにカスタムアドバイスを生成する学習済みポリシーへ変える」と表現しています。

実際の数字で見る

コーディングタスク（SWE-bench Multilingual）

9言語にまたがるコーディング能力テストです。

精度が2.7ポイント上がり、コストは11.9%下がりました。

エージェント検索（BrowseComp）

私が一番驚いたのはHaikuの数字です。19.7%から41.2%——2倍以上です。

ターミナルコーディング（Terminal-Bench 2.0）

Haiku + Opus AdvisorはSonnet単体より29%スコアが低いです。でも、コストは85%安い。精度がある程度あれば十分な大量処理タスクでは、十分な選択肢です。

実装する

Advisor ToolはClaude APIのベータ機能として利用可能です（2026年3月時点）。実装は tools 配列にAdvisorを追加するだけです。

最小構成のPythonコード

import anthropic
client = anthropic.Anthropic()
response = client.beta.messages.create( model="claude-sonnet-4-6", # Executor max_tokens=4096, betas=["advisor-tool-2026-03-01"], tools=[ { "type": "advisor_20260301", "name": "advisor", "model": "claude-opus-4-6", # Advisor } ], messages=[ { "role": "user", "content": "Goでグレースフルシャットダウン付きの並行ワーカープールを作ってください。", } ],
)

betas=["advisor-tool-2026-03-01"] は必須です。このヘッダーがないとエラーになります。

Executorは model= の最上位で指定し、Advisorは tools 配列の中で指定する——この構造を押さえておけば迷いません。

1リクエストの中で何が起きているか

ExecutorがAdvisorを呼ぶと、1回の /v1/messages リクエストの中で次のことが起きます。

オーケストレーションを自分で組む必要はありません。Advisorをいつ呼ぶかは、Executorが自律的に判断します。

モデルの組み合わせルール

AdvisorはExecutorより高性能なモデルを指定する必要があります。有効な組み合わせは次の通りです。

逆（OpusをExecutorにしてHaikuをAdvisorにするなど）を指定すると、APIが 400 invalid_request_error を返します。

コスト管理：max_uses で呼び出し回数を制限する

max_uses でAdvisorの呼び出し回数を上限設定できます。

tools=[ { "type": "advisor_20260301", "name": "advisor", "model": "claude-opus-4-6", "max_uses": 3, # 1リクエストあたり最大3回 }
]

上限に達するとExecutorはAdvisorなしで処理を続けます。コストを見積もりやすくするため、最初は小さい値から試すのが無難です。

料金の仕組みはシンプルです。AdvisorのトークンはOpusの料金、ExecutorのトークンはSonnet/Haikuの料金で別々に課金されます。

使用量の内訳は usage.iterations[] で確認できます。

{ "usage": { "input_tokens": 412, "output_tokens": 531, "iterations": [ { "type": "message", "input_tokens": 412, "output_tokens": 89 }, { "type": "advisor_message", "model": "claude-opus-4-6", "input_tokens": 823, "output_tokens": 1612 }, { "type": "message", "input_tokens": 1348, "output_tokens": 442 } ] }
}

type: "advisor_message" がOpusの料金、type: "message" がExecutorの料金です。どのイテレーションでどれだけOpusを使ったかが一目でわかります。

他のツールとの組み合わせ

Advisor Toolは既存のツールと共存できます。同じ tools 配列に並べるだけです。

tools = [ { "type": "web_search_20250305", "name": "web_search", "max_uses": 5, }, { "type": "advisor_20260301", "name": "advisor", "model": "claude-opus-4-6", }, { "name": "run_bash", "description": "Bashコマンドを実行する", "input_schema": { "type": "object", "properties": {"command": {"type": "string"}}, }, },
]

WebSearchを呼び、Advisorに相談し、Bashコマンドを実行する——これが同じターンの中で起きます。Advisorのプランが次にどのツールを使うかを方向付けることもできます。

私がAdvisor Toolを試したとき、正直「もっと複雑な設定が必要では」と思っていました。実際には tools 配列に4行足すだけでした。構造がシンプルなぶん、モデルの組み合わせとmax_usesの設定を最初にちゃんと決めておくのがポイントで、そこだけ手を抜くとコストが予想外に膨らみます。

TL;DR

• Advisor Tool はExecutor（安いモデル）が複雑な判断の局面だけOpusに相談しながら動く仕組み
• AdvisorはOpusが400〜700トークンの短い指示を返すのみ。ユーザー向けアウトプットは出さない
• Haiku + Opus AdvisorはBrowseCompで19.7%→41.2%、スコアが2倍以上に
• Sonnet + Opus AdvisorはコーディングタスクでSonnet単体より精度UP・コストDOWN（+2.7pt、-11.9%）を同時に実現
• 実装は betas=["advisor-tool-2026-03-01"] と tools 配列へのAdvisor追加だけ
• max_uses でAdvisor呼び出し回数を制限してコストをコントロールできる
• AdvisorはExecutorより高性能なモデルを指定すること（逆は400エラー）
• Advisor TokenはOpus料金、Executor TokenはSonnet/Haiku料金で別々に課金される

投稿 安いモデルがOpus級に賢くなるClaude Advisor Toolの仕組みと実装 は パイソンエンジニア部 に最初に表示されました。

昨日まで続けていた作業を今日また始めようとしたら、Claude が何も覚えていない。プロジェクトの構成を説明し直して、コーディングの好みを伝え直して、「あの難しいバグ、結局どう直したんだっけ」という話を一から始める。毎回ゼロリセット。

Anthropic がリリースした Auto-Memory という機能は、まさにこの問題を解決するために作られました。Claude Code に自前のメモ帳を持たせる仕組みです。そのメモ帳が MEMORY.md というファイルです。

私はこの機能を実際のプロジェクトでテストしました。何を記録するのか、どこに保存されるのか、セッションをまたいで本当に機能するのかを確かめるために。この記事では、テスト結果を交えながら Auto-Memory の全貌を解説します。

Auto-Memory の仕組み

Auto-Memory はデフォルトで有効になっています。Claude Code を最新版にアップデートすれば、設定不要でその日から動き始めます。

あなたが作業している間、Claude は静かに観察しています。どんな情報をメモするかを Claude 自身が判断し、次のカテゴリで記録します。

• プロジェクトのパターン：ビルドコマンド、テストの流れ、コードベースの構造
• デバッグの知見：難しいバグの解決策と根本原因
• アーキテクチャのメモ：重要なファイル、モジュール間の関係、中核となる抽象化
• あなたの好み：コミュニケーションスタイル、作業習慣、使うツール

これらは手動で入力する必要はありません。Claude が自分で判断して書き残します。

保存場所

Auto-Memory のファイルは以下の場所に保存されます。

~/.claude/projects/<project>/memory/

<project> の部分は Git リポジトリのルートパスに基づきます。同じリポジトリ内のサブディレクトリはすべて同じメモリディレクトリを共有します。

Git ワークツリーを使っている場合は、各ワークツリーごとに別々のメモリディレクトリが作られます。Git リポジトリの外では、カレントディレクトリがフォールバックとして使われます。

フォルダの中身は次のような構成になります。

~/.claude/projects/<project>/memory/
├── MEMORY.md # 毎セッション冒頭に読み込まれるメインインデックス
├── debugging.md # デバッグ履歴と繰り返し発生する問題のメモ
└── ... # Claude が必要に応じて作成するトピック別ファイル

MEMORY.md がメインのエントリポイントです。Claude が保存したすべての情報のインデックスとして機能し、新しいセッション開始時に自動的に読み込まれる唯一のファイルです。

200行制限について

Claude のシステムプロンプトに読み込まれるのは MEMORY.md の先頭 200 行だけです。これはとても重要な仕様です。

MEMORY.md が長くなってきたら、Claude は詳細なメモを debugging.md や api-conventions.md といった別のトピックファイルに移し、メインファイルを短くコンパクトに保つことが期待されています。トピックファイルは起動時には読み込まれず、Claude がセッション中に必要と判断したときだけ参照します。

実際の流れはこうなります。

1. 新しいセッションが始まり、MEMORY.md の先頭 200 行が読み込まれる
2. 特定のデバッグ履歴が必要になったら、Claude が debugging.md をその場で読む
3. 新しい知見を得たら、MEMORY.md または関連するトピックファイルに書き込む

テストしていて気づいたのですが、これはバックグラウンドで動くプロセスではありません。セッション中に Claude がメモリディレクトリを読み書きする様子をリアルタイムで確認できます。

CLAUDE.md と MEMORY.md の違い

「CLAUDE.md があるのになぜ MEMORY.md が必要なのか」と思うのではないでしょうか。

CLAUDE.md は Claude Code の当初からある設定ファイルです。あなたが Claude に守ってほしいルール、好み、指示を書いておく場所です。

MEMORY.md はまったく別の役割を持ちます。

あなたが書くものではありません。Claude が自分で作成し、自分で更新するファイルです。

一番シンプルな説明はこうです。CLAUDE.md はあなたが Claude に渡す指示書、MEMORY.md は Claude 自身のメモ帳。MEMORY.md には Claude が作業を通じて学んだことが蓄積されます。あなたの好み、繰り返し現れるプロジェクトのパターン、うまくいったコマンド、失敗したコマンド、過去のセッションで役立ったメモなどです。

まとめると次の通りです。

この 2 つが揃うと、セッション冒頭の Claude がかなり「知っている状態」で始まります。

Claude Code のメモリ階層

Claude Code は CLAUDE.md と MEMORY.md だけで動いているわけではありません。実際にはレイヤー構造になっています。

基本原則は「より具体的な指示が優先される」です。プロジェクトレベルの CLAUDE.md は、ユーザーのグローバルメモリより優先されます。Auto-Memory もプロジェクトレベルにスコープされているため、特定のプロジェクト内での作業にのみ適用されます。

もう一つ覚えておくと便利なのが CLAUDE.local.md です。このファイルは自動的に .gitignore に追加されるため、サンドボックス URL やローカルテストのメモなど、チームと共有したくないプライベートな設定を書く場所として使えます。

新しいセッション開始時、Claude は以下のレイヤーから文脈を読み込みます。

1. 組織のポリシー（存在する場合）
2. プロジェクトレベルの CLAUDE.md（チーム共有の指示）
3. 個人の ~/.claude/CLAUDE.md（個人の好み）
4. MEMORY.md の先頭 200 行（Claude が蓄積したメモ）

つまり最初のプロンプトを打つ前から、Claude はプロジェクトの慣習、あなたの好み、前回までのセッションで学んだ文脈をすでに持った状態で動いています。

実際に動かしてみる

実際のプロジェクトで試した手順を紹介します。

1. Claude Code をアップデートする

Auto-Memory を使うには最新版が必要です。

claude update

バージョンを確認します。2.1.76 以降であれば対応しています。

claude --version

2. テスト用プロジェクトを作成する

mkdir test-claude-memory && cd test-claude-memory
git init

ここで git init が重要です。Claude Code はメモリの保存場所を Git リポジトリのルートで決めています。Git リポジトリでないプロジェクトでは、プロジェクトレベルのメモリは期待通りに機能しません。

Claude Code を起動します。

claude

3. 実際に作業してみる

Auto-Memory はセッションを開いただけではファイルを作りません。何かを一緒に作業してから、Claude がメモを取り始めます。私は LangChain で RAG パイプラインを作るよう指示しました。

LangChain でシンプルな RAG パイプラインを作って

作業が進んだあと /memory コマンドを実行すると、Auto-Memory がオンになっていること、そして 3 つのオプションが表示されます。

Option 1: User Memory グローバルな ~/.claude/CLAUDE.md を開きます。すべてのプロジェクトをまたいで適用したい個人の好みや習慣を書いておく場所です。あなたが管理するファイルです。

Option 2: Project Memory 現在のプロジェクトの CLAUDE.md を開きます。コーディング規約やアーキテクチャの決定など、チーム全体で共有したいコンテキストが入ります。ソース管理にコミットできます。これもあなたが書き管理するファイルで、Claude は読むだけです。

Option 3: Open Auto-Memory Folder Claude が自分で管理するメモリディレクトリを開きます。MEMORY.md とトピック別ファイルがここにあります。

4. Auto-Memory のオン/オフを切り替える

/memory コマンドを実行すると Auto-memory: on という行が表示されます。その行を選択してエンターを押すだけで Auto-memory: off に切り替わります。

探索的な作業をしていて記録に残したくないとき、あるいは一度きりのセッションを実行するときに便利です。

新しいプロジェクトを始めたら /memory コマンドを最初に実行する習慣をつけておくと良いと思います。トグルの状態を確認しながら、メモリが積み上がる前にファイルの保存場所を把握できます。

5. セッションをまたいでテストする

本当に機能しているかを確かめるために、Claude Code を完全に閉じて新しいセッションを起動し、コンテキストを一切渡さずにこう聞きました。

このプロジェクトについて何を知っている？

Claude は前のセッションで MEMORY.md に書き込んだ内容をもとに、プロジェクトの詳細な概要を返してきました。これが Auto-Memory の設計通りの動作です。

Auto-Memory を制御する方法

Auto-Memory はデフォルトでオンですが、状況に応じてオフにしたいケースもあります。

特定のプロジェクトだけオフにする

プロジェクトの設定ファイルに以下を追加します。

// .claude/settings.json
{ "autoMemoryEnabled": false
}

このプロジェクトだけ Auto-Memory が無効になり、他のプロジェクトには影響しません。

すべてのプロジェクトでオフにする

ユーザーレベルの設定ファイルに同じ設定を書きます。

// ~/.claude/settings.json
{ "autoMemoryEnabled": false
}

グローバルに無効化されます。

CI 環境で強制オフにする

CI パイプラインや自動化環境で Claude Code を使う場合は、環境変数が最も確実です。

export CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 # 強制オフ
export CLAUDE_CODE_DISABLE_AUTO_MEMORY=0 # 強制オン

この環境変数は /memory トグルや settings.json の設定よりも優先されます。CI セッションで意図せずメモが蓄積されるのを防ぐには、これが一番確実です。

メモリファイルを直接編集する

MEMORY.md はただのマークダウンファイルなので、いつでも開いて編集できます。

/memory コマンドから選択してシステムエディタで開くか、ターミナルから直接アクセスすることもできます。

open ~/.claude/projects/<your-project>/memory/MEMORY.md

古くなったメモを消したり、整理し直したりするのに使えます。プロジェクトが大きく変わったタイミングで見直すと、Claude の文脈理解がより正確になります。

TL;DR

• Auto-Memory は Claude Code がセッションをまたいで文脈を保持するための仕組み。デフォルトオン、設定不要
• MEMORY.md は Claude 自身が書き更新するメモ帳。あなたが書く CLAUDE.md とは別物
• 新しいセッション開始時に読み込まれるのは MEMORY.md の 先頭 200 行のみ。詳細はトピック別ファイルに切り出される
• メモリの保存場所は ~/.claude/projects/<project>/memory/。Git リポジトリである必要がある
• /memory コマンドでトグル・確認・ファイルへのアクセスがすべてできる
• プロジェクト単位・グローバル・CI 環境変数で細かく制御可能

投稿 Claude Code の MEMORY.md とは何か？Auto-Memory の仕組みと使い方を完全解説 は パイソンエンジニア部 に最初に表示されました。

正直に言うと、それは全然悪くないです。そういう使い方でも、十分に役に立ちます。何も問題はないです。

でも、それだけで終わっていませんか？

みんなが小さな作業にClaudeを使っている間、目の前に転がっている一番大きなメリットを完全に見落としています。

Claudeは、あなた専属の学習コーチになれます。

チャットボットじゃないです。検索エンジンでもないです。

コーチです。学習の計画を設計して、あなたの理解度をテストして、どんな複雑な概念もわかるレベルまで噛み砕いて、世界中の最高の学習リソースを示してくれる。そういう存在です。

速く学べる人と、いつまでも足踏みしたままの人の違いは、頭の良さじゃないです。費やせる時間の差でもないです。

正しいシステムを持っているかどうか、それだけです。

これから紹介する6つのプロンプトが、そのシステムです。

1. 20時間で何でも学ぶ

ほとんどの人が聞きたくない事実があります。

何かを学ぶ最初の20時間が、一番重要です。

その20時間のウィンドウが、まったくの初心者から「実際に使える」レベルへ連れていってくれます。でもほとんどの人は、この大事な20時間を間違ったことに、間違った順番で、間違ったフォーカスで費やしてしまいます。最短ルートで進める時間を、丸ごと無駄にしてしまうんです。

Claudeはその問題をすぐに解決してくれます。

プロンプト：

私は[トピック]を20時間で学びたいです。完全な初心者です。
構造化された学習プランに分解してください。
最初に何に集中すべきか、何を無視していいか、
そして初心者がよくやる一番大きなミスは何かを教えてください。

返ってくるのは、ロードマップです。

曖昧なものじゃないです。実際に優先順位がついていて、初心者がはまりやすいポイントを把握していて、「どこから始めて何をスキップするか」が明確なプランが返ってきます。

それだけで何日もの無駄が消えます。

2. 1ページのチートシートを作る

脳は、あなたが思っている以上に吸収しています。

本当の問題は「記憶できないこと」じゃないです。「必要なときに引き出せないこと」です。

何かを実際に使おうとしているとき、情報がどこにあったか思い出せなくなります。ノートを掘り返す。ブックマークをひっくり返す。タブを何個も開き直す。その繰り返しで、作業のたびに止まってしまいます。そういう体験、心当たりがある人は多いと思います。

1ページのチートシートがその問題を完全に解決してくれます。

プロンプト：

[トピック]の1ページチートシートを作ってください。
キーコンセプト、フレームワーク、よくあるミス、
そして30秒でスキャンできるクイックリファレンスセクションを含めてください。

印刷して手元に貼る。作業中も開いたままにしておく。

思っている以上の頻度で手が伸びます。

3. 限界まで続くクイズ

読むだけは、思っているより全然身になりません。本当に。

本を手に持って、ページの上で目を動かすこと。これは学習者としてできる中で一番受動的な行動のひとつです。この点については研究がはっきりした結論を出しています。検索練習、つまり記憶から情報を引き出してクエスチョンに答えることは、何度も読み返すことを毎回上回ります。読み返しはずっと気持ちいいですが、頭には残りにくいです。

問題は、良い問題を作ること自体がかなりの手間だということです。どこが重要で、どこが弱点になりそうかを把握した上で質問を設計しないといけない。それは決して簡単な作業じゃないです。

Claudeがその作業を代わりにやってくれます。しかも、うまく。

プロンプト：

[トピック]についてクイズを出してください。
最初は簡単にして、正解するたびに難しくしてください。
間違えたら、なぜ間違いなのかを説明して、フォローアップの質問をしてください。
10問連続で正解するまで続けてください。

このプロンプト1つで、自分でも気づいていなかった理解の穴がすべて露わになります。

4. 学習プランを作る

ほとんどの人が新しいことを学ぼうとして途中で諦めるのは、難しすぎるからじゃないです。

階段ではなく、壁に正面からぶつかったからです。

基礎が固まる前に上級教材に飛び込んでしまう。すると混乱する。すると嫌になる。すると諦めて、自分の理解力が足りないせいだと思い込む。でも本当の問題は、学ぼうとした順番だけです。

学習プランがその順番を直してくれます。

プロンプト：

[トピック]の学習プランを作ってください。
ゼロから始めて、上級まで進んでください。
各段は、その前の段の上に積み上がるようにしてください。

そこから出てくるすべての概念に、着地できる場所ができます。何もランダムに感じなくなります。「なぜこれを学んでいるのか」が、常に明確なままで進めます。

5. 最高の学習リソースを探す

すべてのリソースが同じ質じゃないです。

これは意見じゃなくて、ただの事実です。

人生の見方を永遠に変えてくれる本があります。大半の本は平均的なものです。数ヶ月分の混乱を一気に解消してくれるYouTubeチャンネルがあります。大半のチャンネルは午後の時間を無駄にさせます。問題は、実際に時間を投資してみるまで、どっちかわからないことです。

Claudeはどんな個人よりも多くのジャンルの本・コース・ドキュメントを学習データとして持っています。どの本から始めるか、どのコースが今の自分のレベルに合っているかを聞くのに、これ以上適した相手はいないです。使わない手はありません。

プロンプト：

[トピック]を学ぶための最高のリソースは何ですか？
本、無料コース、YouTubeチャンネル、ポッドキャスト。
どれから始めるべきか、そしてその理由も教えてください。

「理由」の部分が、多くの人が気づく以上に大事です。

理由があることで、そのリソースが今の自分のレベルに合っているかどうかを判断できます。最終的に行きたい場所だけじゃなく、今どこにいるかを基準にリソースを選べるようになります。

6. フェインマン・テクニック

リチャード・フェインマンは、キャリアを通じてひとつのことに取り憑かれていました。シンプルに説明できないなら、まだ本当には理解していない。理解したと思っているだけだ、と。

この手法は、居心地が悪いです。それが目的です。

プロンプト：

私が[トピック]を12歳の子どもに説明するように話します。
何かが不明瞭なとき、または説明なしに専門用語を使ったときは、その場で止めてください。
話し終わったら、私が正しかったこと、間違っていたこと、残っているギャップを教えてください。

あとは話すだけです。タイピングでもいいです。自然に感じる方で。

Claudeは、何かが成立していない瞬間に止めてきます。自分では気づかないまま使っていた専門用語を指摘してきます。説明の中でうまくごまかしていた穴を見つけてきます。話し終わると、理解がしっかりしている部分とそうでない部分を正直に整理して返してくれます。

そういうフィードバックをほとんどの人は受け取れないです。

なぜなら、ほとんどの人は相手に遠慮するからです。正直なフィードバックをくれる人は、現実にはほとんどいないです。

Claudeは遠慮しません。

それがまさに必要なことです。

使い方の変化

一番速く学ぶ人が他の人より賢いわけじゃないです。ただ、より良いシステムと、より正直なフィードバックを持っているだけです。

長い間、そういった個人に合わせたコーチングは高価で、手に入りにくく、または運が必要でした。適切な人を知っているか、家庭教師を雇えるお金があるか、たまたま良いメンターと出会えるかどうか。そういうことでした。

もうそうじゃないです。

これら6つのプロンプトはすべて、今日から無料で試せます。今すぐ。Claudeを開いて、小さいタスクをこなすためのツールとしてじゃなく、本気で何かを身につけるためのパートナーとして扱うだけです。

ずっと後回しにしてきたひとつのトピックを選んで、この6つのプロンプトを全部通してみてください。

以前の学び方には戻れなくなります。

TL;DR

• 20時間学習プラン → 初心者向けに優先順位を整理した具体的なロードマップが即座に出てくる。何日もの試行錯誤が消える
• 1ページのチートシート → 記憶より引き出しが問題。手元に常に置けるクイックリファレンスを作ってもらう
• 限界までクイズ → 読むだけでは身につかない。10問連続正解まで続くテストで、自分の穴を全部炙り出す
• 学習ラダー → 挫折の原因は難易度じゃなく順番。ゼロから上級まで積み上がる学習順を設計してもらう
• 最高のリソース探し → 「なぜ」付きで推薦してもらうことで、今の自分のレベルに合ったリソースを選べる
• フェインマン・テクニック → 12歳に説明するつもりで話す。Claudeが遠慮なく指摘してくる。それが一番正直なフィードバック

投稿 Claudeを使えば何でも100倍速く学べる。その6つのプロンプト は パイソンエンジニア部 に最初に表示されました。

私が試したとき、出てきたのはペンギンでした。

ペンギンか。まあ悪くないけど、できればドラゴンが良かったな。

そう感じたことはありませんか？

実は Claude Code には、バディを再抽選する公式の機能がありません。最初に割り当てられたバディが、ずっとあなたのバディです。

「buddy-gacha」はその制限を回避するオープンソースの CLI ツールです。 設定ファイルを書き換える前にどんなバディが出るか確認できるので、気に入ったものだけ適用できます。

/buddy コマンドとは

まず前提を整理します。

/buddy は Claude Code のターミナル上で動作するコマンドです。実行すると、バーチャルペットが一匹「孵化」します。種族・名前・ステータスがランダムで決まり、コーディング中に画面の片隅に表示されます。

かわいいけど、なぜか毎回コモンが出る気がする。

これは気のせいではなく、仕組みによるものです。

なぜ毎回同じバディが出るのか

Claude Code のバディは、~/.claude.json の中にある userID という値をもとに生成されます。

同じ userID → 毎回同じバディ。

ランダムに見えますが、実際には固定です。userID が変わらない限り、何度 /buddy を実行しても同じ種族が出てきます。

buddy-gacha はこの仕組みを使います。ランダムな userID を生成し、Claude Code が内部で使っているのと同じハッシュロジックでバディをシミュレートします。ディスクには何も書き込まれていない段階で結果が見えて、気に入ったものを選んだときだけ ~/.claude.json が更新される、という流れです。

インストールとコマンド一覧

Bunインストール（インストール後、ターミナルを再起動）

curl -fsSL https://bun.sh/install | bash

npm で一発インストールできます。

npx buddy-gacha --help

インタラクティブモードで起動するとこうなります。

buddy-gacha

10 件の候補がレアリティ順に並びます。選ぶと ~/.claude.json が更新されます。

実行前に Claude Code を完全に終了してください。 起動中に設定ファイルを書き換えると競合が起きます。buddy-gacha 自身もこれを警告してくれます。

レアリティを指定して探す

特定のレアリティを狙うときは --rare フラグを使います。レアリティは 1〜5 の数値で指定します。

Legendary が出るまでロールし続けるコマンドはこちらです。

buddy-gacha --rare 5

フィルタを組み合わせる

フラグは組み合わせられます。

光沢のある（Shiny）Epic を狙うなら：

buddy-gacha --rare 4 --shiny

Legendary のドラゴン限定で探すなら：

buddy-gacha --rare 5 --species dragon

最大ロール数を指定して、Shiny Legendary ドラゴンを本気で狙うなら：

buddy-gacha --rare 5 --shiny --species dragon --max-attempts 100000

この組み合わせは期待値として 1 万回に 1 回の確率です。--max-attempts は十分に大きくして、気長に待ちましょう。

レアリティを「以上」で絞りたい場合は --min-rare が使えます。

buddy-gacha --rare 4 --min-rare

これは Epic か Legendary のどちらかが最初に出た時点で止まります。

実際に試してみた

インタラクティブモードで動かしてみました。

buddy-gacha

まず「Claude Code を閉じてから実行してください」という警告が出ます。これは素直に従った方がいいです。

10 件の候補が生成されました。内訳はこうです。

npx buddy-gacha --count 10 Buddy Gacha Make sure Claude Code is not running, or config writes may conflict
Generating 10 random buddies...
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1.  LEGENDARY | duck | @ eyes | Tail: 1f0034
2.  EPIC | dragon | ✦ eyes | Tail: cf1673
3.  RARE | duck | ✦ eyes | Tail: 53a348
4.  RARE | duck | × eyes | Tail: 8cf1e2
5.  UNCOMMON | blob | · eyes | Tail: e13f73
6.  UNCOMMON | cat | @ eyes | Tail: 92ce9b
7.  UNCOMMON | robot | ◉ eyes | Tail: 0cc739
8.  COMMON | rabbit | ◉ eyes | Tail: 0d0aae
9.  COMMON | rabbit | ° eyes | Tail: 602255
10.  COMMON | snail | ◉ eyes | Tail: 55a927
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ legendary: 1 |  epic: 1 |  rare: 2 |  shiny: 0
Choose a buddy (1-10), or enter 0 to cancel: 

今のバディを手放したくなかったので、ここで止めました。

buddy-gacha が ~/.claude.json の userID を書き換え、コンパニオンキャッシュをクリアして、再起動を促してくれます。再起動後に /buddy を実行すると、新しいバディの孵化画面が出ます。

今のバディに愛着があるなら、これは一方通行なので慎重に。

TL;DR

• Claude Code の /buddy コマンドでバーチャルペットが生成される
• バディは ~/.claude.json の userID から決まるため、公式のリセット手段はない
• buddy-gacha は書き込み前に結果をプレビューできるリセットツール
• npm install -g buddy-gacha でインストール
• --rare / --shiny / --species / --min-rare フラグで狙いを絞れる
• 実行前に Claude Code を完全終了すること

投稿 Claude Codeに仮想ペットが飼える。/buddyコマンドを試してみた は パイソンエンジニア部 に最初に表示されました。

history | grep を打って、3週間前に使ったコマンドを必死に探す。あのオプション何だったっけ、と10分悩む。エラーメッセージをコピーしてブラウザに貼る。ChatGPTで聞いて、答えを持ってきてまたターミナルに貼る。

この往復、何往復やってきたか数えたくもないです。

2026年、この作業の仕方は変わりました。

ターミナルにAIが入ってきたからです。コマンドを手で打ち込む場所ではなくなりました。AIに話しかけると、ファイルを開き、コードを書き、エラーを修正し、Gitにコミットする。そういうことが、コマンドライン上で完結するようになっています。

私が実際に試してみて手放せなくなったAI搭載のCLIツールを7つ紹介します。インストールコマンドも全部載せます。

1. Aider — 複数ファイルを横断して直してくれるAI

Aiderがほかのツールと違うのは、チャットではなくファイルを直接編集するところです。

「この関数をJWT認証に書き直して」と言うと、関連する5つのファイルを開いて修正し、説明付きのGitコミットまで自動で作ります。コーヒーを飲んでいる間に終わります。

GPT-4o、Claude 3.7 Sonnet、DeepSeekなど主要なモデルに対応しています。Ollama経由でローカルモデルも使えます。音声でコードの指示を出す「Voice-to-Code」機能もあります。

python -m pip install aider-install
aider-install
# プロジェクトのディレクトリに移動
cd /your/project
# Claude 3.7 Sonnetで起動する場合
aider --model sonnet --api-key anthropic=<your-key>
# DeepSeekで起動する場合
aider --model deepseek --api-key deepseek=<your-key>
# o3-miniで起動する場合
aider --model o3-mini --api-key openai=<your-key>

複数ファイルにまたがるリファクタリングが多い人は、まずここから試してみてください。

2. Gemini CLI — 無料でここまでできるのかというGoogle製エージェント

Gemini 3 FlashとProにターミナルから直接アクセスできます。

質問に答えるだけでなく、コマンドを実行したり、ファイルシステムを探索したり、エラーをその場で修正したりする動きをします。GoogleのVideo Generation（動画生成）、Deep Research、Notebook LMといったAIツールとも連携できます。

npmで入れるだけです。

npm install -g @google/gemini-cli

無料枠の範囲でAIエージェントを試したい場合、現時点で最も手軽な入口の一つです。有料サービスを契約する前に、まずこれで感触をつかむのもありです。

3. Atuin — 「あのコマンドなんだっけ」を永久に卒業する

history | grep に頼っている間は、検索できるのはコマンドの文字列だけです。

Atuinはシェル履歴をSQLiteデータベースに保存して、複数のマシン間で同期します。2026年のバージョンからはセマンティック検索が使えるようになりました。オプション名を覚えていなくても「ファイルを再帰的に検索したとき」「先月のDockerビルドのやつ」という意図で過去のコマンドを引き出せます。

curl --proto '=https' --tlsv1.2 -LsSf https://setup.atuin.sh | sh

インストールして既存の履歴を読み込めば、今日からすぐ使えます。「同じコマンドを何度も調べている」という感覚がある人は試してみてください。

4. ShellGPT (sgpt) — ブラウザとターミナルの往復をやめる

ShellGPTはAiderほど大掛かりなものは要らない。ちょっとAIに聞きたいだけ。そういうときのツールです。

ログファイルをパイプで渡して「このエラーを説明して」と聞けます。シェルスクリプトをその場で生成させることもできます。ステージングしている変更からgitのコミットメッセージを自動で作る機能もあります。

pip install shell-gpt
# エラーログをパイプで渡して説明させる
cat error.log | sgpt "このエラーを日本語で説明して"
# コマンドを生成して実行
sgpt --shell "/var/log以下の大きいファイルを探して"

「ちょっと聞くだけでブラウザを開くのが面倒」という場面が、思ったよりたくさんあることに気づきます。

5. Warp — ターミナルアプリそのものを替える選択肢

ツールを追加するより、ターミナルアプリ自体を変えてしまうという考え方です。私は何かターミナルで作業するとき、このツールを最も愛用しています。

WarpはモダンなUIとコード編集機能を組み合わせたターミナルです。Warp専用のAIエージェント「Oz」が内蔵されています。Claude Code、Codex、Gemini CLIなど外部のAIエージェントをWarp上で実行することもできます。個人利用は無料で、月に一定量のAIリクエストが使えます。

「ターミナル自体が使いにくい」と感じている人には、新しいツールを入れるより先にこっちを試した方が早いかもしれません。

6. Goose — プロジェクトごと任せられるオープンソースエージェント

Gooseはコードの提案だけでなく、プロジェクトをゼロから作り、コードを書いて実行し、失敗したらデバッグし、外部APIと連携するところまで自律的に動きます。

どのLLMでも使えます。マルチモデル設定（タスクの重さでモデルを使い分ける）にも対応しています。MCPサーバーとの統合もできます。デスクトップアプリとCLIの両方があります。

brew install block-goose-cli

「エージェントにどこまで任せられるか試したい」という人は、ここから始めるのがわかりやすいです。

7. OpenCode — コードをクラウドに送れない場合の選択肢

業務の都合でコードを外部サーバーに送れないことがあります。OpenCodeはそういう場面で使えます。

75種類以上のLLMプロバイダーを切り替えられます。完全ローカルで動くモデルにも対応しています。特定のベンダーに縛られずにAIエージェントを使いたい人向けです。

# macOS / Linux（常に最新版が入るのでこちらを推奨）
brew install anomalyco/tap/opencode
# npmで入れる場合
npm i -g opencode-ai@latest
# スクリプトで一発インストール
curl -fsSL https://opencode.ai/install | bash

セキュリティポリシーが厳しい環境でも使えるのが実用的なポイントです。

どれから始めるか

全部入れる必要はありません。

Atuinはインストールするだけで今日から使えます。既存のシェル履歴がそのまま検索しやすくなります。何かを覚え直す必要がなく、失うものもないです。まず試すならここです。

ShellGPTはpipで入れてすぐ動きます。ブラウザとターミナルを行き来する習慣を少しずつ減らせます。

Aiderはコードを書いている人向けです。複数ファイルにまたがる修正が多いほど効果が出ます。

GooseとOpenCodeはもう一段踏み込んだエージェント体験を試したいときに。

毎週新しいAIツールが出てきます。全部追いかけると消耗します。この7つの中から1つだけ選んで、まず手を動かしてみてください。

TL;DR

• Aider：ターミナル上のAIペアプログラマー。複数ファイルを直接編集しGitコミットまで自動化
• Gemini CLI：Google製エージェント型シェル。無料枠が手厚く、Google AIサービスと連携可能
• Atuin：シェル履歴をSQLiteで管理。意図で検索できるセマンティック検索が使える
• ShellGPT：軽量なAI連携ツール。ログ解析、コマンド生成、コミットメッセージ生成に使う
• Warp：AI前提で設計されたターミナルアプリ。個人利用は無料
• Goose：オープンソースのAIエージェント。プロジェクトをゼロから丸ごと任せられる
• OpenCode：75種類以上のLLMに対応。コードをクラウドに送れない環境向け

投稿 ターミナルがAIの操縦席になった：2026年に使うべきCLIツール7選 は パイソンエンジニア部 に最初に表示されました。

以前の記事でClaude Managed Agentsの仕組みを解説しました。

でも実際の作り方には触れていなかった。

今回は、最初のClaude Managed Agentを作るまでに何が起きたかをそのまま書きます。

結論から言います。Claude Codeで作るのが一番楽です。ただし、最初に設計をきちんと固めないと、何度も往復することになります。

まず公式ドキュメントとコードサンプルを読んで、エージェントの設計図（ブループリント）を書きました。

• 何を達成させたいか
• 良いアウトプットとはどういう状態か

この2点を明確にしたことで、Claude Codeが一発で本番使用に耐えるエージェントを作れる条件が整いました。

エージェントのブループリント

私が作ることにしたのは、PRレビューエージェントです。

ソフトウェアエンジニアやチームリードが今日から使えるユースケース。それがこの選択の理由です。

定義した内容はこうです：

PRレビューエージェント：プルリクエストを読み込み、コード変更を分析し、構造化されたレビューレポートを出力する。

やること：

• PRのdiffに含まれる変更ファイルをすべて読む
• 変更箇所の周辺コンテキストを把握する
• バグ、コードスメル、セキュリティ問題、テスト不足を検出する
• 変更がコードベースの既存パターンに沿っているか確認する
• 発見事項と修正提案を含む構造化Markdownレポートを書く
• テストスイートを実行してレポートに結果を含める

必要なツール：

• Bash — gitコマンドの実行、diffの取得、テストスイートの実行
• ファイル操作 — 変更ファイルの読み込みとレポートの書き出し
• WebSearch と WebFetch — 不明なライブラリやパターンの調査（任意）

良いアウトプットの条件：

• Summary、Issues Found、Suggested Fixes、Test Results の4セクションで構成されたMarkdownファイル
• シニアエンジニアがそのまま読めるクオリティ。手直し不要な状態

制約：

• 最大30ターン — 徹底したレビューに十分で、かつ暴走しない範囲
• セッションあたりの予算上限 $2.00 — コストを予測可能に保つ
• パーミッションモード acceptEdits — レポートへのファイル書き込みを自動承認し、シェルコマンドはゲートで制御

このブループリントがそのままClaude Codeへのプロンプトになりました。

Claude Code × Claude Managed Agents ドキュメント

ブループリントが固まったので、ターミナルでClaude Codeを起動しました。

使ったプロンプトはこれです：

以下のURLでClaude Managed Agentsのドキュメントを読んでください：
https://platform.claude.com/docs/en/managed-agents/overview
https://platform.claude.com/docs/en/managed-agents/quickstart
その後、AnthropicのPython SDKとManaged Agentsベータを使って、
本番対応のPRレビューエージェントを作ってください。
エージェントの要件：
1. ディレクトリパスを入力として受け取る
2. git diffを実行して変更ファイルを取得する
3. 変更ファイルとその周辺のコードベースコンテキストをすべて読む
4. バグ、コードスメル、セキュリティ問題、テスト不足を特定する
5. pytestで既存のテストスイートを実行する
6. 4つのセクション（Summary、Issues Found、Suggested Fixes、Test Results）を持つ 構造化Markdownレビューレポートを作成する
要件：
- ツールタイプに agent_toolset_20260401 を使用する
- max_turns を30、max_budget_usd を2.00に設定する
- session.status_idle を含むすべてのストリーミングイベントを適切に処理する
- 適切なエラーハンドリングを含める
- エージェントIDと環境IDを保存して再利用できるようにする
まずドキュメントを読んでから、ステップごとに作成してください

Claude Codeは最初にドキュメントを読みました。両方のページをフェッチした。

プロンプトにURLを入れた理由がここにあります。公式ドキュメントを読んでから作らせることで、正確なAPIの形を理解した上でコードを生成します。

その後、プロジェクトディレクトリを確認してから3つのファイルを生成しました。

• pr_review_agent.py — 389行、エージェントの完全な実装
• requirements.txt — 依存関係は1つだけ：anthropic>=0.49.0
• README.md — 161行、使い方・アーキテクチャ・CLIリファレンスの完全ガイド

アーキテクチャはManaged Agentsのドキュメントに記載されたパターンそのものになっています。

エージェント作成 — 正しいツールタイプと詳細なシステムプロンプト：

agent = client.beta.agents.create( name="PR Review Agent", model="claude-sonnet-4-6", system=SYSTEM_PROMPT, tools=[ # agent_toolset_20260401 は完全な組み込みツールセットを有効にします： # bash、ファイルread/write/edit/glob/grep、ウェブ検索、ウェブフェッチ {"type": "agent_toolset_20260401"}, ],
)

環境 — 無制限ネットワークのクラウドコンテナ：

environment = client.beta.environments.create( name="pr-review-env", config={ "type": "cloud", "networking": {"type": "unrestricted"}, },
)

セッション — 適切な制限と実行ごとの説明的なタイトル：

session = client.beta.sessions.create( agent=agent_id, environment_id=environment_id, title=f"PR Review — {repo_name} — {timestamp}", max_turns=30, max_budget_usd=2.00,
)

ストリーミング — メッセージ送信前に開き、すべてのイベントタイプを処理：

with client.beta.sessions.events.stream(session.id) as stream: client.beta.sessions.events.send( session.id, events=[{"type": "user.message", "content": [...]}], ) for event in stream: match event.type: case "agent.message": for block in event.content: print(block.text, end="", flush=True) case "agent.tool_use": print(f"\n [tool: {event.name}]", flush=True) case "session.status_idle": print("AGENT FINISHED") break case "session.status_error": print(f"[ERROR]: {event.error}") break case "session.budget_exceeded": print("[WARN] Budget limit reached") break

IDの永続化 — エージェントIDと環境IDを agent_config.json に保存して再利用：

def get_or_create_agent(client, config, fresh): if not fresh and "agent_id" in config: print(f"[agent] Reusing existing agent: {config['agent_id']}") return config["agent_id"], config # ... 新しいエージェントを作成

2回目以降のレビューは同じエージェントと環境を再利用します。新しく作り直す場合は --fresh フラグを使います。

動作確認

実際に動かすのは3ステップです：

pip install -r requirements.txt
export ANTHROPIC_API_KEY="sk-ant-..."
python pr_review_agent.py /path/to/your/repo

初回実行時にエージェントと環境が作成され、IDが agent_config.json に保存されます。

2回目以降はそのIDを再利用します。

まとめ

Claude Managed Agentを作る一番簡単な方法を探しているなら、Claude Codeが答えです。

一番大事なのはブループリントを書くステップです。Claude Codeは説明した通りに作ります。説明を明確にすることが全てです。

試してみたい方は、上のプロンプトをそのまま使えます。

ドキュメントを読んで、ブループリントを書いて、あとはClaude Codeに任せてください。

TL;DR

• Claude Managed Agentsは長時間・非同期タスク向けのエージェント基盤です
• 作る前にブループリント（何をするか・良いアウトプットとは何か）を書くと一発で完成に近いものができます
• Claude Codeにドキュメント URLを渡すことで、正確なAPI仕様を読んだ上でコードが生成されます
• エージェント・環境・セッションの3層構造を理解することが実装の核心です
• IDを保存して再利用することで、毎回の起動コストを抑えられます

投稿 Claude CodeでClaude Managed Agentをゼロから作った話 は パイソンエンジニア部 に最初に表示されました。

「自分でも作れそう」と思って始めます。
そしてすぐに気づきます。

あれ、これ…コードより設定の方が多くない？

ループ処理を書きます。ツールのラッパーを書きます。コンテキスト管理を書きます。セッション管理を書きます。サンドボックスを用意します。エラーハンドリングを書きます。

そして1行も「本当にやりたいこと」を書いていないまま、週が終わります。

その苦しみには名前があります

「インフラの罠」。

AIエージェント開発の本当のボトルネックは、AIの能力ではありません。
それを動かすための配管工事です。

ほとんどの開発者が詰まるのはここです。プロンプトではありません。ツール呼び出しのラッパー実装で詰まります。コンテキストが溢れてセッションが死ぬことで詰まります。本番途中でエラーが出て、AIのデバッグではなくインフラのデバッグをするはめになります。

これはあなたの実力の問題ではありません。
構造的な問題です。

AnthropicはAPIをまた一つ増やしたわけではありません

2026年4月、AnthropicはClaude Managed Agentsを発表しました。

正直に言います。最初は「また新しいAPIか」と思いました。
(私はAIツールの追いかけには慎重な方です。毎週出る新ツールを全部試すのは時間の無駄だと思っています。)

でもこれは違いました。

Anthropicが渡してきたのはAPIではありません。ランタイムです。

つまり、エージェントが動く「環境そのもの」を提供するということです。ファイルを読んで、コードを実行して、Webを検索して——その全部を、Anthropicのクラウド上で、すでに動いている状態で使えるようになりました。

2つのものが同時にリリースされました

まず整理します。今回のリリースは2本立てです。

Claude Managed Agents — Anthropicのクラウド上で動く、フルマネージドのエージェント実行環境です。あなたはエージェントを定義してタスクを投げるだけで、コンテナ・ツール・セッション管理はすべてAnthropicが面倒を見ます。

Claude Agent SDK（旧称: Claude Code SDK） — PythonとTypeScriptのライブラリです。Claude Codeのエージェントループを自分のアプリに組み込めます。実行インフラは自分で用意しますが、難しい部分はすでに作られています。

同じ問題を解決しますが、エージェントをどこで動かすかが違います。

• SDK → 自分のインフラで動かす
• Managed Agents → Anthropicのクラウドで動かす

ほとんどの人にとって、今すぐ恩恵を受けやすいのはManaged Agentsの方です。この記事ではこちらを掘り下げます。

4つの概念を理解すれば全部わかります

Claude Managed Agentsは4つの概念で成り立っています。これさえ押さえれば、全体像が一気にクリアになります。

Agent（エージェント）
あなたが設定するものです。モデル、システムプロンプト、使うツール、MCPサーバー。一度作ればIDで何度でも参照できます。

Environment（環境）
エージェントが作業するクラウドコンテナです。Python、Node.js、Goなどが最初から入っていて、ネットワークアクセスも設定済みです。

Session（セッション）
エージェントが特定のタスクを実行する「作業インスタンス」です。ファイル・会話履歴・コンテキストがすべてここに保持されます。

Events（イベント）
あなたのアプリとエージェントの間を流れるメッセージです。ユーザーの指示、ツールの実行結果、ステータス更新、レスポンスのストリームが含まれます。

コードで書くとこうなります：

import anthropic
client = anthropic.Anthropic()
# エージェントを一度作成。IDで何度でも再利用できる
agent = client.beta.agents.create( model="claude-sonnet-4-6", system="You are a software engineer. Fix bugs, run tests, and report results.", tools=[{"type": "bash"}, {"type": "file_operations"}, {"type": "web_search"}], name="bug-fixer"
)
print(agent.id) # このIDを保存しておく

セッションを開始してタスクを投げます：

# エージェントが必要なパッケージをインストールした環境を作成
environment = client.beta.environments.create( packages=["pytest", "requests"]
)
# エージェントと環境を紐づけてセッションを開始
session = client.beta.sessions.create( agent_id=agent.id, environment_id=environment.id
)
# タスクをイベントとして送信
response = client.beta.sessions.events.create( session_id=session.id, content="auth.py のテストを見つけて修正してください"
)

これで完了です。 エージェント定義・環境・セッション。あとはClaudeがやります。

エージェントは「1回答えて終わり」ではありません

ここが重要なポイントです。

従来のChatGPT的なAI利用のイメージ：質問する→答えが返ってくる→終わり。

Managed Agentsは違います。

Claudeはプロンプトを受け取ったら、ループを回し続けます。
「タスクを評価する → ツールを呼ぶ → 結果を処理する → また評価する」
これを繰り返して、仕事が完了するまで自律的に動き続けます。

「auth.py のテストを修正して」というタスクを例にすると：

• ターン1 → Bashでテストスイートを実行。3つ失敗していることを確認
• ターン2 → auth.py とテストファイルを読んで問題を理解
• ターン3 → ファイルを修正してテストを再実行。3つとも通過
• 最終ターン → ツール呼び出しなしのテキスト応答。タスク完了

async for event in client.beta.sessions.stream( session_id=session.id, event={ "type": "user", "content": "auth.py のテストを見つけて修正してください" }
): # Claudeが何をしているかリアルタイムで見える if event.type == "assistant_message": print(event.content) # 最終結果を取得 if event.type == "result": print(f"完了: {event.result}") print(f"使用ターン数: {event.num_turns}") print(f"コスト: ${event.total_cost_usd:.4f}")

ツール呼び出し・結果・ターンの全履歴がリアルタイムで流れてきます。ブラックボックスではありません。

コンテキストが溢れる問題、自動で解決されます

DIYのエージェントで最も頭を悩ませるのがコンテキストウィンドウ問題です。

ターンが増えるたびにコンテキストが積み上がります。プロンプト・ツール定義・ファイルの中身・コマンドの出力・会話履歴——全部が乗っかります。上限に達した瞬間、セッションが死にます。

Managed Agentsはこれを自動で処理します。

上限に近づくと、古い会話履歴を要約してスペースを確保しながら、最近のやり取りと重要な判断内容を保持し続けます。セッションは止まりません。

3つのコントロール

思考の深さ（Effort level）

各ターンでClaudeがどれだけ深く考えるかを設定します。トークン消費とコストに直結するので、意図的に設定してください。

最大ターン数とコスト上限

session = client.beta.sessions.create( agent_id=agent.id, environment_id=environment.id, max_turns=20, # 20ターンで停止 max_budget_usd=0.50 # または$0.50消費で停止
)

どちらかの上限に達した場合、理由が明示されたresultが返ってきます。セッションIDを保存しておけば後から再開できます。

パーミッションモード

• default — 事前承認外の操作はコールバック経由で確認します
• acceptEdits — ファイル編集は自動承認。シェルコマンドは確認します
• bypassPermissions — 全操作を確認なしで実行します（CI環境・隔離コンテナ専用）

タスクの途中で指示を変えられます

セッションが動いている最中に、追加のイベントを送ってリダイレクトできます：

client.beta.sessions.events.create( session_id=session.id, content="やっぱり auth_token のテストだけ修正して。login のテストは触らないで"
)

完了を待つ必要はありません。おかしな方向に進んでいたら、その場で修正できます。

組み込みツール一覧

手動でエージェントを作る場合、時間を最も食うのがツールのラッパー実装です。エラーハンドリング・結果をコンテキストに戻す処理——全部自分で書く必要があります。

Managed Agentsでは、これが全部すでに完成しています。

ファイル操作

• Read — コンテナ内の任意ファイルを読みます
• Write — 新規ファイルを作成します
• Edit — 既存ファイルを修正します

検索

• Glob — パターンでファイルを検索します
• Grep — 正規表現でコンテンツを検索します

実行

• Bash — シェルコマンド・スクリプト・git操作・パッケージインストール・テスト実行ができます

Web

• WebSearch — インターネット検索ができます
• WebFetch — 任意URLのページコンテンツを取得・解析します

オーケストレーション

• Task — サブエージェントを生成して独立した作業を委任します
• Skill — 再利用可能なワークフローを呼び出します
• AskUserQuestion — 処理を一時停止して人間に確認します
• TodoWrite — セッションをまたいだマルチステップ作業を追跡します

組み込みツールに加えて、MCPサーバーで外部サービスを接続したり、独自のカスタムツールを定義することもできます。

始め方

Claude Managed Agentsは現在ベータ版です。

APIアカウントがあればデフォルトで使えます。すでにClaude APIキーを持っているなら、今すぐ始められます。

必要なものは以下の3つです：

• platform.claude.com で発行したClaude APIキー
• managed-agents-2026-04-01 ベータヘッダー（SDKを使えば自動で付与されます）
• PythonまたはTypeScriptのSDK

pip install anthropic

export ANTHROPIC_API_KEY=your-api-key

20行以内で動く最初のエージェント：

import anthropic
import asyncio
client = anthropic.Anthropic()
async def main(): agent = client.beta.agents.create( model="claude-sonnet-4-6", system="You are a helpful engineering assistant.", tools=[{"type": "bash"}, {"type": "file_operations"}], name="my-first-agent" ) environment = client.beta.environments.create( packages=["pytest"] ) session = client.beta.sessions.create( agent_id=agent.id, environment_id=environment.id, max_turns=10, max_budget_usd=0.25 ) async for event in client.beta.sessions.stream( session_id=session.id, event={"type": "user", "content": "このディレクトリのPythonファイルを一覧表示して"} ): if event.type == "result": print(event.result) print(f"コスト: ${event.total_cost_usd:.4f}")
asyncio.run(main())

なお、以下の3つの機能はリサーチプレビュー段階で、別途アクセスリクエストが必要です：

• Outcomes（成果の追跡）
• Multi-agent coordination（複数エージェントの協調）
• Persistent memory（永続メモリ）

アクセスリクエストは claude.com/form/claude-managed-agents からできます。

正直な評価

Claude Managed Agentsが解決するのは実在する問題です。

エージェントループ・コンテキスト管理・ツール実行・セッション継続性——これらを自前で構築するのに数週間かかっていた作業が、設定ファイルとAPIコール数行になりました。プロダクション品質のエージェントを速く作りたい人には、意味のある前進です。

ただし、勘違いしないでほしい点があります。

インプットの質がアウトプットの質を決める、この原則は変わりません。どんなにインフラが整っても、曖昧なプロンプト・設計の甘いエージェント・目的の不明確なタスクは、そのまま曖昧な結果を返します。

ツールが上手くなっても、考える力が不要になるわけではありません。 むしろ「何をClaudeに任せるか」「どう指示するか」の設計力がより問われるようになります。

TL;DR（要点まとめ）

• Claude Managed Agents = Anthropicのクラウド上で動くフルマネージドのエージェント実行環境。インフラ構築を自分でやらなくて済みます。
• 4つの概念: Agent（設定）・Environment（実行環境）・Session（作業インスタンス）・Events（メッセージ）
• エージェントループ: タスク完了まで自律的にツールを呼び続けます。1ターンでは終わりません。
• コンテキスト管理が自動: 上限に近づくと古い履歴を要約して継続。セッションが死ななくなります。
• コントロール手段: 思考の深さ・最大ターン数・コスト上限・パーミッションモードで制御できます。
• 今すぐ使えます: APIキーがあればベータとして利用可能。pip install anthropic で開始できます。
• インプットの質は変わりません: ツールが整っても、設計力と指示の質がアウトプットを決めます。

投稿 AnthropicがClaude Managed Agentsを発表。AIエージェント開発の「本当のボトルネック」がついに解消されます は パイソンエンジニア部 に最初に表示されました。

この記事では、無料で登録できる LINE 公式アカウントを使い、LINE アプリ上で有価証券のティッカー（銘柄コード）を入力すると最新の終値を返すプログラムを実装します。ngrok というツールを使って、ローカルマシンで動作する Web アプリをインターネットに公開します。Web アプリは Flask で作成します。うまくいくとちょっと感動すると思います。

1. おおまかな実装の流れ

LINE Bot を Python で実装するおおまかな流れは以下のようになります。

1. LINE 公式アカウントの作成と設定
2. 開発環境構築
3. オウム返し LINE Bot の作成とメッセージ処理ロジックの実装
4. 入力したティッカーの最新終値を返すプログラムの作成

2. 技術スタックの大まかな解説

3. 環境構築

ここでは、Windows と Mac の両方で Python の環境をセットアップし、LINE Bot 開発の準備を進める手順を解説します。Python 3.12 以上をインストール済みとします。

3-1. LINE 公式アカウントの作成と設定

3-1-1. LINE Business ID の登録

https://www.lycbiz.com/jp/service/line-official-account/ にアクセスし、LINE アカウントまたはメールアドレスで登録します。デフォルトでは LINE ビジネス ID と個人の LINE アカウントはひも付いていません。本解説ではひも付けません。

3-1-2. LINE 公式アカウントの作成

次に、作成した Business ID でログインし、アカウント名、企業名、業種などの必要情報を入力します。

公式アカウントが作成されたら、「LINE Official Account Manager へ」のボタンを押して LINE 公式アカウントマネージャーにログインしてください。

ウェルカムで QR コードが表示されますので友だち登録しておきましょう。

友だち追加すると下図のように表示されます。何かメッセージを送っても表示されるのはデフォルトのメッセージです。これから任意のメッセージを返すボットを実装していきます。

3-1-3. Messaging API の有効化

ユーザーと双方向のコミュニケーションを実現するための API を有効化します。API（Application Programming Interface）はプログラム同士が連携するための窓口です。ここでは私たちのアプリと LINE 社が提供しているプラットフォームとの窓口です。

LINE 公式アカウントマネージャーで画面右上にある「設定」をクリックし（①）、左側の「Messaging API」を選択して「Messaging API を利用する」をクリックします（②）。

次に表示される画面で名前とメールアドレスを入力してください。

続いてプロバイダーを作成します。

プライバシーポリシーと利用規約の入力画面になりますが、ここは何も入力せず OK ボタンを押します。

次のような画面が表示されます。これで Messaging API が有効になりました。

3-1-4. API キーの取得

「Channel Secret」と「Channel Access Token」を取得します。これらは後でプログラムで使用します。

Messaging API の画面では表示されている Channel Secret をコピーします。Channel Access Token は LINE Developers コンソールから発行します。下図の枠囲みからリンクを開いてください。

「LINE Developers コンソール」で表示されるプロバイダーから先ほど作成したものを選択します。

「Messaging API 設定」タブを選択し、

画面の下の方にあるチャンネルアクセストークン欄で発行します。下の図はすでに発行後のためボタンが表示されていませんが、発行前であればここに表示されます。発行されたらアクセストークンをコピーして保存しておいてください。

3-1-5. 応答設定

次は応答設定を行います。デフォルトではユーザーからのメッセージに対して毎回一律応答するメッセージが設定されています。不要なのでオフにしておきます。また、ユーザーからのメッセージに対して、これから実装するプログラムで応答するための設定も行います。

LINE 公式アカウントマネージャーのチャット (①) タブで「Webhook」にチェックを入れ (②)「応答メッセージ」のチェックを外します (③)。

ここまでで LINE 側の設定が終わりましたので次はプログラム実装とサーバーの設定を行います。

3-2. LINE Bot SDK for Python とその他ライブラリのインストール

まずは仮想環境を有効にして、以下のライブラリをインストールします。

pip install line-bot-sdk flask yfinance python-dotenv

LINE Bot SDK for Python

• Python で LINE Bot を作成するためのライブラリです。

Flask

• Web サーバーを構築するために Flask をインストールします。

yfinance（株価ボットの場合）:

• 株価データを取得するために yfinance ライブラリをインストールします。

python-dotenv（環境変数管理）:

• Channel Access Token や Channel Secret などの機密情報を安全に管理するために使用します。

3-3. ngrok のインストールと設定

ngrok は、ローカルで開発した LINE ボットをインターネット上に公開するためのツールです。

1. アカウントの登録 (無料)
2. 登録後の Welcome 画面に OS ごとのインストール方法が表示されますので、案内に従ってダウンロード・インストールしてください。
3. インストール後は ngrok config add-authtoken をターミナルで実行するのを忘れないでください。

4. オウム返し Bot の実装

これで環境が揃いましたので、Python と Flask を使って LINE Bot の基本的なメッセージ処理ロジックを実装する方法を解説します。まずはシンプルなオウム返し Bot です。

以下のような流れでオウム返しします。

flowchart TD A[ユーザーがメッセージ送信] --> B[LINEがcallback関数を呼び出し] B --> C{署名検証OK?} C -->|NG| D[エラー返却] C -->|OK| E[handle_message関数実行] E --> F[受信メッセージを取得] F --> G[同じメッセージで返信] G --> H[処理完了]

4-1. プロジェクト構造

まずは以下のディレクトリ構成を作成します。

project/
├── app.py
└── .env

4-2. 環境変数の設定

次はあなたの公式アカウントであることを証明するため、先ほどコピーしたチャンネルアクセストークンとチャンネルシークレットを使います。

セキュリティのため、チャンネルアクセストークンとチャンネルシークレットは直接コードに書き込まず、.env ファイルに記載し、python-dotenv ライブラリを使って読み込みます。

先ほどコピーしておいたチャンネルアクセストークンとチャンネルシークレットに置き換えてください。

CHANNEL_ACCESS_TOKEN='YOUR_CHANNEL_ACCESS_TOKEN'
CHANNEL_SECRET='YOUR_CHANNEL_SECRET'

4-3. app.py の実装

app.py に以下のコードを記述します。LINE アプリでユーザーがメッセージを送信したときに、このプログラムでボットが返事します。Flask という軽量 Web フレームワークを使います。

import os
from dotenv import load_dotenv
from flask import Flask, request, abort
from linebot.v3 import WebhookHandler
from linebot.v3.exceptions import InvalidSignatureError
from linebot.v3.messaging import Configuration, ApiClient, MessagingApi, ReplyMessageRequest, TextMessage
from linebot.v3.webhooks import MessageEvent, TextMessageContent
# 環境変数を読み込み
load_dotenv()
app = Flask(__name__)
# 環境変数の確認
channel_access_token = os.getenv('CHANNEL_ACCESS_TOKEN')
channel_secret = os.getenv('CHANNEL_SECRET')
# LINE Bot API の設定
configuration = Configuration(access_token=channel_access_token)
handler = WebhookHandler(channel_secret)
@app.route("/callback", methods=['POST'])
def callback(): # リクエストヘッダーから署名検証のための値を取得 signature = request.headers['X-Line-Signature'] # リクエストボディを取得 body = request.get_data(as_text=True) app.logger.info("Request body: " + body) # 署名を検証し、問題があれば例外を発生させる try: handler.handle(body, signature) except InvalidSignatureError: print("Invalid signature. Please check your channel access token/channel secret.") abort(400) return 'OK'
@handler.add(MessageEvent, message=TextMessageContent)
def handle_message(event): # 受信したメッセージをそのまま返す（オウム返し） reply_text = event.message.text with ApiClient(configuration) as api_client: line_bot_api = MessagingApi(api_client) line_bot_api.reply_message_with_http_info( ReplyMessageRequest( reply_token=event.reply_token, messages=[TextMessage(text=reply_text)] ) )
if __name__ == "__main__": port = int(os.environ.get("PORT", 8000)) app.run(host="0.0.0.0", port=port, debug=True)

下から 2 行目の以下のコードはポートの設定です。ポートとは「家の玄関に新しい扉を作って、特定の人だけが入れるようにする」仕組みです。つまり 8000 番の玄関にお客さんが来たらこのプログラムが実行されます。この数値は次の ngrok で使う数値と合わせる必要があります。

port = int(os.environ.get("PORT", 8000))

実装したらターミナルで app.py を実行します。

python app.py

以下のような表示になります。

(.venv) h_ikuma:~/PycharmProjects/LINE BOT % python app.py * Serving Flask app 'app' * Debug mode: on
WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead. * Running on all addresses (0.0.0.0) * Running on http://127.0.0.1:8000 * Running on http://192.168.31.209:8000
Press CTRL+C to quit * Restarting with stat * Debugger is active! * Debugger PIN: 142-356-595

4-4. Webhook の設定

ボットを実際に稼働させるためには、LINE Developers で Webhook URL を設定します。Webhook とは「LINE から自動で連絡をもらうための、あなたのサーバーの連絡先」です。要するに「何かあったら、この住所（URL）に教えて」と登録するのが Webhook URL の役割です。

ngrok の起動

• app.py を実行しているターミナルとは別のターミナルを開いて ngrok http 8000 を実行します。app.py に記載したポート番号と合わせます。
• 表示される https:// から始まる公開 URL（例: https://xxxx.ngrok-free.app）をコピーします。
• 無料アカウントではこの URL は ngrok を起動するたびに変わりますので、その都度 LINE 側の Webhook URL 設定を修正する必要があります。

Messaging API の画面で Webhook URL を表示し、先ほどコピーした URL を貼り付け、末尾に /callback を付けて保存します。

callback とは「何かが起きたら、あらかじめ決めておいた処理を自動で実行する」仕組みです。LINE Bot の場合なら「メッセージが届いたら、私のサーバーに教えて（callback）」という設定をしているわけです。

ngrok でインターネット上に公開しているので、メッセージが届くと Messaging API から app.py に連絡が届き、オウム返しで返信します。

4-5. Bot のテスト

これで、あなたのローカルで実行されている LINE Bot は稼働しているはずです。実際に作成した公式アカウントに何かメッセージを入力してみてください。同じメッセージをオウム返しするはずです。

オウム返ししなかったら app.py を実行しているターミナルを確認してください。エラーが表示されていたらターミナルをクリックして Ctrl+C でアプリを停止させ、エラー箇所を修正したら再度 app.py を実行してください。

5. 株価を返すように修正

次はティッカーを入力したら最新の終値を返すようにしましょう。以下のような流れになります。

flowchart TD A["ユーザーがティッカーシンボル送信<br/>例: 'aapl'"] --> B["LINEがcallback関数を呼び出し"] B --> C{"署名検証OK?"} C -->|NG| D["エラー返却"] C -->|OK| E["handle_message関数実行"] E --> F["メッセージを正規化<br/>strip().upper()"] F --> G["get_stock_price関数呼び出し<br/>yfinanceで株価取得"] G --> H{"株価取得成功?"} H -->|成功| I["株価メッセージ作成<br/>'AAPL: $150.25'"] H -->|失敗| J["エラーメッセージ作成<br/>'ティッカーが見つかりません'"] I --> K["LINE Messaging APIで返信"] J --> K K --> L["処理完了"]

app.py と同じ階層に ticker.py を作成し、以下のコードを実装します。

import yfinance as yf
def get_stock_price(ticker_symbol): """ 指定されたティッカーシンボルの最新終値を取得する Args: ticker_symbol (str): ティッカーシンボル（例: 'AAPL', '^N225'） Returns: tuple: (success: bool, result: float or str) 成功時: (True, 株価) 失敗時: (False, エラーメッセージ) """ try: ticker = yf.Ticker(ticker_symbol) hist = ticker.history(period="1d") if hist.empty: return False, f"ティッカー '{ticker_symbol}' のデータが見つかりませんでした。" price = hist['Close'].iloc[-1] return True, price except Exception as e: return False, f"エラーが発生しました: {str(e)}"
if __name__ == "__main__": # 日経225と、存在しないティッカーを取得 success, result = get_stock_price("^N225") if success: print(f'日経225: {result:.2f}') else: print(result) success, result = get_stock_price("hoge") if success: print(f'hoge: {result:.2f}') else: print(result)

次は app.py を以下のように get_stock_price をインポートし、handle_message を修正します。

from ticker import get_stock_price
@handler.add(MessageEvent, message=TextMessageContent)
def handle_message(event): # 受信したメッセージをそのまま返す（オウム返し） # reply_text = event.message.text # ユーザーからのメッセージを取得 user_message = event.message.text.strip().upper() # 大文字に変換してスペースを削除 # ティッカーシンボルとして株価を取得 success, result = get_stock_price(user_message) if success: # 株価を取得できた場合 reply_text = f"{user_message}: ${result:.2f}" else: # エラーが発生した場合 reply_text = result with ApiClient(configuration) as api_client: line_bot_api = MessagingApi(api_client) line_bot_api.reply_message_with_http_info( ReplyMessageRequest( reply_token=event.reply_token, messages=[TextMessage(text=reply_text)] ) )

修正したら LINE アプリで試してください。例えば Apple 社の株価を取得するには aapl と入力します。

その他にもいろいろなティッカーで遊んでみてください。

うまくいきましたか？ 期待したとおり株価が返ってきたら嬉しかったのではないでしょうか？ うまくいかなかったら次のトラブルシューティングを確認してください。

6. トラブルシューティング

6-1. まずはここを確認（クイックチェックリスト）

• [ ] Flask アプリ（app.py）が起動している（コンソールに Running on http://127.0.0.1:8000 が表示）
• [ ] ngrok http 8000 を別ターミナルで実行中（https の公開 URL が表示）
• [ ] LINE Developers の Webhook URL が https://<ngrokのURL>/callback になっている
• [ ] LINE Official Account Manager の「Webhook」が有効
• [ ] .env の CHANNEL_ACCESS_TOKEN と CHANNEL_SECRET が正しい（余計な空白・改行なし）
• [ ] 端末がスリープしていない

6-2. 症状別の対処

A. 返信が一切返ってこない

• Webhook の疎通確認

  • LINE Developers → Messaging API → Webhook 設定 → 「接続確認」を押す
  • 成功しない場合は URL の末尾に /callback が付いているか、ngrok が起動中か確認

• ログの確認

  • app.py 側のコンソールにリクエストログ（Request body）が出ているか
  • 何も来ない場合、ngrok の URL が変わっていないか再確認

• ヘルスチェック

  • 公開 URL 直下 / は 200 を返すはず

  curl -i https://<ngrokのURL>/

B. 400/403（Invalid signature）になる

• CHANNEL_SECRET が間違っている可能性
  • WebhookHandler(channel_secret) に設定している値が最新か確認
• Webhook を自分で curl POST しても X-Line-Signature がないため 400 が正常
  • Webhook の実テストは必ず LINE 側の「接続確認」か、実メッセージで行う

C. 401 Unauthorized になる

• CHANNEL_ACCESS_TOKEN が無効 or 期限切れ
  • LINE Developers でトークンを再発行し、.env を更新 → アプリ再起動

D. 404 や 405 Method Not Allowed

• Webhook パスのミス
  • @app.route("/callback", methods=['POST']) と LINE 側 URL /callback の一致を確認
• メソッド不一致
  • Webhook は POST のみ。GET では 405 になる

E. 500 Internal Server Error（Python 例外）

• 例外メッセージを確認して修正
  • 例えば event.message.text を前提にして画像やスタンプが来ると例外に
  • 本ガイドのコードは TextMessageContent のみをハンドルしていることを再確認

F. たまに動くが、しばらくすると動かない

• ngrok の URL が起動の度に変わる（無料プラン）
  • 変わったら Webhook URL を更新
• PC/Mac のスリープ・ネットワーク切断
  • スリープ設定を見直す or こまめに再接続

G. yfinance で株価が取れない/遅い

• ティッカーの打ち間違い、マーケット休場、ネットワーク不安定

投稿 Pythonで最新の株価を返すLINE BOT構築ガイド: ngrok, flask, yfinance は パイソンエンジニア部 に最初に表示されました。

Cursor を使う上で欠かせないのがショートカットキーです。ここではよく使うショートカットキーを厳選して表にまとめました。一気に覚えるのは難しいですが、一つずつ身につけていってください。

覚えるときのコツとして、「メニューやアイコンの隣にはショートカットキーが書いてある」という法則を覚えておいてください。

下の図のように画面上部のメニューやアイコンにカーソルを合わせるとショートカットキーが表示されます。始めは、メニューやアイコンをクリックして実行するのは、出し方ありませんが、その時どのようなショートカットキーが使えるか、合わせて覚え、次回からはそのショートカットキーを使って実行するようにすれば、だんだん身についていきます。

ショートカットキーで操作すると、より効率的に操作できるようになり、その分、試行回数が増えて技術習得が早くなります。

エディタでの編集系

コード実行系

F5 と Ctrl+F5 の違い

ペイン表示/非表示切り替え系

Cursor AI 操作系

コマンドパレット操作系

コマンドパレットとは Cursor の機能を文字列で検索できる機能です。日本語、英語どちらにも対応しています。

その他コードペインに関連するもの

投稿 Cursorで覚えておきたいショートカットキー は パイソンエンジニア部 に最初に表示されました。