Claude Code on KnightLiブログ

How to use academic-research-skills?クロード・コード学術研究スキルキット

Sat, 06 Jun 2026 22:26:00 +0800

Imbad0202/academic-research-skills は、Claude Code の学術研究スキルのセットです。リサーチ、執筆、レビュー、修正から最終仕上げまでの完全なプロセスをカバーしています。目標は、AI に論文を書かせることではなく、退屈な研究支援作業をツール化することです。

README には非常に正確な文があります。AI はパイロットではなく、副操縦士です。文献の検索、引用の整理、ロジックのチェック、シミュレーションのレビューと形式の変換には役立ちますが、実際の問題の定義、方法の選択、結果の解釈、および議論の文章は依然として研究者の責任である必要があります。

どのような機能が含まれていますか?

このプロジェクトは単一のプロンプトではなく、クロードコードスキルとコマンドシステムのセット全体です。 README に記載されているコアモジュールには次のものが含まれます。

ディープリサーチ: ソクラティックファシリテーション、PRISMA システマティックレビュー、意図検出、クロスモデルチェック、および Semantic Scholar API 検証をサポートする 13 エージェントの研究チーム。
学術論文: スタイル調整、執筆品質チェック、LaTeX 強化、視覚化、改訂コーチング、引用変換などを含む 12 エージェントの論文執筆プロセス。
学術論文査読者: 編集長、動的査読者、Devil’s Advocate を含む 7 人のエージェントによる多視点の査読。
アカデミックパイプライン: 適応型チェックポイント、請求検証、マテリアルパスポート、整合性ゲートキーピングを備えた 10 段階のパイプライン。
データアクセスレベルメタデータ: スキルの raw、編集済み、verified_only およびその他のデータアクセスレベルをマークします。
ベンチマークレポートスキーマ: 不誠実な比較を減らすためにベンチマークレポートを制限します。
Artifact Reproducibility Lockfile: 再現実験に関連する設定を記録します。

それは大きな野心を持っています。それは「私に代わって要約を書く」ということではなく、学術的なワークフローを検査、追跡、レビューできる段階に分割することです。

インストール方法

README では、Claude Code プラグインを使用してインストールすることを推奨しています。

1
2

/plugin marketplace add Imbad0202/academic-research-skills
/plugin install academic-research-skills

インストール後、次のことを試すことができます。

`1`	`/ars-plan`

ソクラテス的対話を通じて論文を構成するのに役立ちます。文献レビューを直接テストすることもできます。

`1`	`/ars-lit-review "your topic"`

前提条件は主に次のとおりです。

クロードコードの最新バージョン;
ANTHROPIC_API_KEY;
オプションの Pandoc (DOCX 用);
APA 7.0 PDF 用のオプションの地殻変動およびソースハンセリフ TC。

README には、Codex CLI を使用すると、その兄弟ディストリビューションである academic-research-skills-codex を確認できることも記載されています。つまり、メインリポジトリは Claude Code ネイティブですが、ワークフローコンテンツには Codex バージョンがあります。

人間参加型を強調する理由

このプロジェクトは、「完全に自動化された AI 科学者」という幻想を明確に否定します。 README には、完全に自動化された研究システムは、実装のバグ、結果の錯覚、バグを発見と誤解する、手法の改ざん、引用の錯覚など、多くの失敗モードが引き継がれると述べられています。

学術研究スキルは、人間を排除するのではなく、人間と機械のコラボレーションに焦点を当てるように設計されています。整合性ゲート、クレーム検証、引用アンカー、クロスモデル検証、その他のメカニズムを使用して、AI は困難な作業を支援することはできますが、学術的な責任を引き受けることはできないことを思い出させます。

これは重要です。学術論文において、AI について最も危険なのは、文章のスタイルが機械のようなものではなく、引用、データ、結論が本物のように見えても、実際には支持できないことです。

誰に適していますか?

次のような人に適しています。

論文、レビュー、提案、または反論を執筆している研究者。
文献や引用を体系的に整理する必要がある人。
クロードコードを使用して学術論文の執筆プロセスを管理したい人。
AIにレビューシミュレーションやロジックチェックをしてもらいたい人。
APA、LaTeX、引用の変換とフォーマットに関するサポートが必要な人々。
人間と機械のコラボレーションは受け入れられるが、AI による完全自動原稿配信は望まない人。

「原稿のクリーニング」や「AI利用の痕跡の隠蔽」には向きません。 README には、ヒューマナイザーではないことも明記されています。目標は品質を向上させることであり、不正行為を支援することではありません。

使用のリスク

学術 AI ツールの場合は特に注意してください。

引用は元のテキストに対して手動でチェックする必要があります。
事実とデータはモデルのみに依存することはできません。
論文の意見はあなた自身の研究上の判断に基づいたものでなければなりません。
学校、雑誌、会議には、AI の使用に関する開示要件がある場合があります。
未公開のデータや被写体の情報をモデルに気軽に渡すことはできません。
自動生成されたLaTeX、統計的な説明やグラフもチェックされます。

私のアドバイスは、執筆ツールとしてではなく、リサーチアシスタントやレビューアシスタントとして使用することです。質問したり、抜け穴を見つけたり、形式をチェックしたり、引用を整理したりするのに役立ちますが、重要な議論は自分でコントロールする必要があります。

まとめ

academic-research-skills は現在、学術研究 AI スキルワークフローの完全なセットです。その最も価値のある部分は、「論文を書けること」ではなく、文献、執筆、レビュー、改訂、引用の検証、完全性のチェックを明確な段階に分割することです。

すでに Claude Code を使用していて、本格的な学術論文執筆のタスクを抱えている場合は、真剣に検討してみてください。ただし、覚えておいてください。AI は副操縦士であり、運転手ではありません。学術的責任は最終的に著者にあります。

参考ソース

Imbad0202/学術研究スキル - GitHub

キャリアオプスの使い方は？ Claude Code で求職プロセスを管理する

Sat, 06 Jun 2026 22:26:00 +0800

santifer/career-ops は、Claude Code に基づいて構築された AI を活用した求人検索システムです。求人検索プロセスをスキルモード、ダッシュボード、PDF 生成、バッチ処理に分割し、断片的な操作から管理可能なシステムに求人検索を変えることを目的としています。

就職活動自体は複雑なプロジェクトに非常によく似ています。履歴書、役職、会社、納品、フォローアップ、面接、レビュー、バージョン管理はすべて継続的なメンテナンスを必要とします。キャリアオプスは、これらのタスクを AI エージェントの支援に引き継ぎたいと考えています。

何に適していますか?

これを使用して以下を管理できます。

バージョンを再開します。
ジョブマッチング;
就職活動資料を作成します。
カバーレター;
面接の準備;
バッチ処理位置。
PDF出力; ・納入実績とフォロー状況。

ハイライトは、単にモデルにカバーレターを書いてもらうのではなく、ワークフローエンジンとして Claude Code を使用していることです。

誰に適していますか?

より適したもの:

集中的に仕事を探している人。
さまざまなポジションに合わせて履歴書を調整する必要がある人。
就職活動をシステム化したい方。
クロードコードとコマンドラインに精通している人。
求人応募資料をバッチで作成、整理、レビューする必要がある人。

たまに 1 つまたは 2 つのポジションに応募するだけの場合は、通常の書類とフォームで十分かもしれません。

境界を使用する

求人検索の自動化を過剰に行うのは簡単です。

履歴書で経験を捏造することはできません。
AI によって生成されたコンテンツは信頼性を維持する必要があります。
低品質の素材を大量に納品しないでください。
面接の準備は、AI の回答を暗記するだけでは不十分です。
個人データ、会社情報、職務記録は保護されなければなりません。

AI はそれを整理して表現するのに役立ちますが、実際の体験を提供することはできません。

＃＃まとめ

キャリアオプスの価値は、就職活動を運用システムとして扱うことにあります。真剣に仕事を探している人にとっては、一時的にAIに履歴書を変更させるよりも便利です。

すでに Claude Code を使用していて、多くの求職プロセスを行っている場合は、このプロジェクトを参照する価値があります。簡単な仕事に応募するだけの場合は、最初にフォームと履歴書のテンプレートを使用しても問題ありません。

参考ソース

サンティファー/キャリア運用 - GitHub

味覚スキルの使い方は？ AI フロントエンド生成に美的制約を追加する

Sat, 06 Jun 2026 22:22:56 +0800

Leonxlnx/taste-skill は、非常に興味深いフロントエンドエージェントスキルプロジェクトです。その目標は、別の UI コンポーネントライブラリを作成することではなく、Codex、Cursor、Claude Code などの AI プログラミングツールに一連の「美的制約」を追加して、一見 AI のように見えるテンプレートインターフェイスを減らすことです。

プロジェクトの README では、これを Anti-Slop フロントエンドフレームワークと呼んでいます。この表現は少し大げさですが、方向性は非常に正確です。AI のフロントエンドを書くときの最大の問題は、多くの場合、コードを書けないことではなく、デフォルトのレイアウトが平坦すぎる、階層が弱すぎる、スペースが自動的に生成されているように見え、モーションエフェクトやフォントが判断されないことです。

正確には何ですか?

テイストスキルは基本的に、インストール、コピー、ペーストできるエージェントスキルのセットです。これらは実行時の依存関係やブラウザプラグインではなく、AI エージェントの動作ルールです。

フロントエンドを生成する際、モデルはさらに注意を払う必要があります。

レイアウト: レイアウトはカードを中央に配置するだけではありません。
タイポグラフィ: フォントサイズ、フォントの太さ、および行の高さは階層的である必要があります。
間隔: 空白、余白、密度はシーンと一致する必要があります。
モーション: モーションエフェクトは、アニメーションを追加するだけでなく、インタラクションに役立つ必要があります。
設計言語: 製品タイプに基づいて設計言語を推測します。
スロップ防止: テンプレート、プレースホルダー、中途半端な出力を避けます。

このタイプのスキルの価値は、「プロンプトをもう少し書く」ことではなく、フロントエンドの美的判断を再利用可能なルールに修正して、さまざまなプロジェクトで使用できるようにすることです。

インストール方法

README では、npx skills add を使用してインストールすることを推奨しています。

`1`	`npx skills add https://github.com/Leonxlnx/taste-skill`

デフォルトのフロントエンド設計スキルのみをインストールする場合は、次を指定できます。

`1`	`npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend"`

従来の動作に依存している場合は、v1 をインストールすることもできます。

`1`	`npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend-v1"`

プロジェクトには、SKILL.md をプロジェクトに直接コピーしたり、コンテンツを ChatGPT / Codex 会話に貼り付けて使用したりできるとも記載されています。言い換えれば、特定のプラットフォームにバインドする必要はありません。

どのようなスキルが組み込まれていますか?

テイストスキルは 1 つのファイルではありません。 README にはさまざまなスキルが記載されています。

スキル	インストール名	目的
味覚スキル	`design-taste-frontend`	デフォルトのフロントエンドの美的ルール。現在、v2 はまだ実験段階です。
味-スキル-v1	`design-taste-frontend-v1`	従来の動作を維持する
gpt-tasteskill	`gpt-taste`	GPT / Codex に適した厳密なバージョン
画像からコードへのスキル	`image-to-code`	最初に参照画像を生成し、次に分析して、コードを記述します。
再設計スキル	`redesign-existing-projects`	まず既存のプロジェクトを監査してから、UI を変更します。
ソフトスキル	`high-end-visual-design`	高級感、柔らかさ、余白たっぷりのビジュアルディレクション
ミニマリストのスキル	`minimalist-ui`	Notion/Linear スタイルの抑制された製品 UI
残忍なスキル	`industrial-brutalist-ui`	インダストリアル、スイスのフォント、強いコントラストを持つ実験的なスタイル
アウトプットスキル	`full-output-enforcement`	半分の出力とプレースホルダーを抑制するために使用されます。

Web、モバイル、ブランドボードの参照画像を生成するための画像生成スキルもあります。これらはコードを直接出力しませんが、視覚的な参照を生成し、それが実装のために Codex、Cursor、または Claude Code に渡されます。

使い方に合わせて

AI に背景フォームの作成を依頼するだけの場合は、要件を述べるだけで十分かもしれません。ただし、やりたい場合は次のようにします。

製品公式ウェブサイト;
SaaS ダッシュボード;
モバイルページ;
ブランドのランディングページ;
ポートフォリオ;
ハイエンドツールインターフェイス;
既存のプロジェクト UI の再設計。
参照イメージからフロントエンドを復元します。

そうなると、テイストスキルがさらに役に立ちます。 AI が大量のカードを生成するのを待ってから少しずつ叱り返すのではなく、「これはどのような種類のインターフェイスであるべきか」を事前に制約するのに役立ちます。

私なら次のように使います:

新しいプロジェクトは最初に design-taste-frontend を使用します。
Codex/GPT プロジェクトは gpt-taste を試すことができます。
既存のプロジェクトの改訂には redesign-existing-projects を使用します。
明確なスタイルがある場合は、minimalist-ui、high-end-visual-design、または industrial-brutalist-ui を追加します。
AI が常に TODO を残すか、コードを省略する場合は、full-output-enforcement を追加します。

これは普遍的な美的ボタンではありません

Taste Skill は「AI フロントエンドの出力がテンプレート化されすぎている」という問題を解決しますが、デザイナーの代替品ではありません。

いくつかの境界を明確にする必要があります。

ブランドのポジショニングを定義することはできません。
すべての世代が見栄えが良いことを保証することはできません。
フロントエンドの美学の基礎を持っている人が二次的な判断を下すのに適しています。
スキルがどれほど詳細であっても、製品の背景、対象ユーザー、機能の優先順位を提供する必要があります。
既存の設計システムを使用するチームは、スキルが内部仕様をカバーできないようにすべきではありません。

言い換えれば、それは「フロントエンドで生成された美的足場」に似ています。デフォルトの下限値を上げることはできますが、最終的な効果は、レビュー、スクリーンショットの撮影、CSS の調整、および実際のデバイスの確認に依存します。

＃＃まとめ

taste-skill の価値は、多くのフロントエンド設計の経験をエージェントが実行可能なルールに変えることです。 Codex、Cursor、Claude Code などのツールでは、「コードは書けるが品質が落ちやすい」という欠点を補うのに非常に適したスキルです。

AI をよく使用してフロントエンドページを生成する場合、特に大きなグラデーション、大きな丸い角、全画面カード、ランダムなアイコン、レイヤーレスのテンプレートのようなインターフェイスにうんざりしている場合は、AI を出発点として使用できます。しかし、これをデザインディレクターとして考えないでください。実際のプロジェクトでは、やはり自分自身で選択する必要があります。

参考ソース

Leonxlnx/taste-skill - GitHub

Claude Opus 4.8 リリース：Anthropic がコーディングとエージェントタスクをさらに強化

Fri, 29 May 2026 15:22:47 +0800

Anthropic は 2026 年 5 月 28 日に Claude Opus 4.8 をリリースした。これは Opus シリーズの新バージョンであり、公式の位置づけは明確だ。世代交代を示す名前変更ではなく、Opus 4.7 を土台に、コーディング、エージェントタスク、推論、専門知識を使う作業の能力をさらに高めたものだ。

今回の更新は通常のチャットユーザーにも意味がある。ただし、より注目すべきなのは Claude Code と長時間実行される agent のシナリオだ。Anthropic は Opus 4.8 を、より信頼できる協働者として説明している。複雑なタスクの中で、いつ質問すべきか、いつ前に進むべきか、いつ慎重に扱うべきかをよりよく判断できる、ということだ。

今回の更新の要点

Claude Opus 4.8 はすでに提供開始されており、価格は据え置きだ。公式はあわせて、いくつかの関連する変更も強調している。

Opus 4.8 は、コード、エージェント能力、推論、知識作業の評価で前世代からさらに向上している。
claude.ai ユーザーは、Claude がタスクに投入する effort を制御できる。
Claude Code に dynamic workflows が追加され、より大規模な問題を扱えるようになった。
Opus 4.8 の fast mode は約 2.5 倍の速度で動作でき、以前のモデルの fast mode より 3 倍安い。

これらをまとめて見ると、Anthropic はモデルスコアを少し上げただけではない。「複雑なタスクを長時間実行する」ことを軸に、プロダクトの形を変えている。モデルの強化はその一部にすぎず、タスク制御、ワークフロー分解、コスト構造も同じくらい重要だ。

Claude Code ユーザーが特に注目すべき理由

Claude Code のようなコーディング agent にとって最も怖いのは、単一の関数を書けないことではなく、実際のリポジトリの中で迷うことだ。ファイルを読み、依存関係を理解し、テストを走らせ、エラーを確認し、方針を修正し、そのうえで変更範囲を妥当に保つ必要がある。

Opus 4.8 の訴求点は、まさにこれらの問題に近い。

agentic tasks により適している。つまり、モデルが継続的に計画し、ツールを呼び出し、結果を観察し、戦略を調整する必要があるタスクだ。
judgement をより重視しており、不確かなときに止まって確認できる。自信満々に間違ったまま進むのではない。
dynamic workflows によって、Claude Code は大規模で多段階の問題を扱いやすくなる。

これらの能力が実プロジェクトで安定して働くなら、Claude Code の使い方は「明確な目標を渡して前に進めてもらう」ものに近づく。単に一部のコードを補完させるだけではなくなる。

effort 制御が意味するもの

Anthropic は今回 claude.ai に effort 制御を追加した。意味は直接的だ。ユーザーが、モデルにどれくらい力を使わせるかを調整できる。

これは日常利用でも実用的だ。簡単な質問に深い推論は不要だが、複雑なタスクではモデルに少し長く考えさせる価値がある。以前は多くのユーザーが、プロンプトで「もっと慎重に」や「早く答えて」と表現するしかなかった。今はこの種の制御がプロダクト層に入り始めている。

開発者にとっても、これは一つのシグナルだ。今後の agent 製品は「どのモデルを選ぶか」だけを見せるのではなく、速度、コスト、推論の深さ、ツール呼び出しの積極性、リスク許容度といった実行戦略も見せるようになる。

fast mode のコスト変化は重要

公式によると、Opus 4.8 の fast mode は約 2.5 倍の速度に達し、同時に以前のモデルの fast mode よりかなり低コストになる。

この点はモデル能力のニュースに隠れやすいが、実際のワークフローでは重要だ。多くの agent タスクは一度だけ実行されるのではなく、繰り返し実行される。

初稿を生成する
テストを走らせる
失敗を修正する
もう一度テストを走らせる
review に応じてさらに修正する

fast mode が十分に安ければ、チームはトップモデルを重要タスクでたまに使うだけでなく、高頻度のフローにも組み込みやすくなる。速度とコストが下がって初めて、agent は「デモとして面白いもの」から「日常の道具」へ移りやすくなる。

Opus 4.7 との関係

Opus 4.8 は、利用しやすさに向けた強化版に近い。Opus 4.7 の位置づけを引き継ぎつつ、重点をさらにコーディング、エージェントタスク、専門的な作業へ押し進めている。

Anthropic の表現を見る限り、Opus 4.8 は単に回答がよくなっただけではない。より協働がうまくなった。タスクの中で、いつ情報が必要か、いつ方針が不安定か、いつ大きな変更の前に確信を固めるべきかを、より明確に扱えるはずだ。

この種の能力は、単一の benchmark だけでは判断しにくい。本当の検証は、大規模リポジトリ、複雑な業務ルール、長いコンテキストのタスク、複数回にわたる修正の中での挙動を見る必要がある。

AI コーディング競争への影響

2026 年のモデル競争は、「チャット能力」から「仕事をこなせるか」へ明確に移っている。OpenAI、Anthropic、Google、xAI はいずれも、モデルとツールチェーンをより強く結びつけている。モデルが推論を担い、ツールが実行を担い、プロダクト層がタスクを制御可能な範囲に保つ。

Claude Opus 4.8 のリリースは、この流れを引き継いでいる。焦点は単一の能力を誇示することではなく、三つの部分を強化することだ。

モデル自体がコードとエージェントタスクにより適している。
Claude Code がより大きなワークフローを分解できる。
プロダクト層が effort や fast mode のような実行制御を提供し始めている。

開発者にとっての実際の意味は、モデル選びで「どれが一番賢いか」だけを見てはいけないということだ。使っているツールに合うか、安定してツールを呼べるか、長いタスクのコストが許容できるか、失敗したときに修正しやすいかも見る必要がある。

私の見方

Claude Opus 4.8 は実務寄りの更新だ。誇張された新しいパラメータを物語の中心に置くのではなく、agent ワークフローに最も必要なものを補い続けている。判断力、安定性、速度、コスト、タスク制御だ。

すでに Claude Code を使っているなら、今回の更新は早めに試す価値がある。特に、実際のリポジトリにある長いタスクで比較するとよい。たとえば、モジュール横断のリファクタリング、テスト修正、ドキュメント同期、複雑な bug の特定などだ。

通常のチャットユーザーにとって、Opus 4.8 の変化は新世代モデルの発表ほどすぐに衝撃的には感じられないかもしれない。それでもプロダクトの方向性としては、Anthropic が Claude を「複雑な仕事を信頼して実行できる」方向へ押し進め続けていることを示している。

原文リンク：Introducing Claude Opus 4.8

CLIProxyAPI：Codex、Claude Code、Gemini CLI を統一 API として包み込む

Sun, 24 May 2026 10:03:33 +0800

CLIProxyAPI は、かなり「現場の工夫」らしさがあるプロジェクトです。新しい大規模モデルを作るものでも、単なる API 転送サービスでもありません。もともとインタラクティブで、CLI 中心で、OAuth ログインに依存しがちな AI ツール群を、統一 API サービスとして再パッケージします。

対応対象には Gemini CLI、OpenAI Codex、Claude Code、Amp CLI、AI Studio Build、そして上流の OpenAI 互換サービスが含まれます。つまり、解きたい問題はこうです。

手元に CLI ツール、サブスクリプションアカウント、OAuth ログイン状態がある。これらの能力を、普通の API を呼ぶように自分のクライアント、スクリプト、IDE、社内サービスへ接続できないか？

CLIProxyAPI の答えは「できる」です。間にプロキシ層を置き、異なる出自の CLI 能力を OpenAI、Gemini、Claude、Codex 互換インターフェイスへ変換します。

本当に解決する痛点

多くの AI コーディングツールは強力ですが、標準の使い方は自動化に向いていません。

たとえば：

Gemini CLI はアカウントログインで使えるが、プログラム側は HTTP API を呼びたい。
Claude Code は対話型コーディングに向いているが、他のクライアントへ接続するとプロトコル差にぶつかる。
Codex CLI は OAuth ログインと Responses 形式の能力を持つが、上位ツールが必ずしも会話方法を知っているわけではない。
チームには複数アカウントがあり、ローテーション、負荷分散、異常アカウントの除外、クォータ確認が必要になる。
一部のツールには OpenAI 形式だけを見せたいが、実際のバックエンドは Gemini、Claude、Codex かもしれない。

CLIProxyAPI の位置づけは、これらのツールとクライアントの間に入る「プロトコル適配層」です。

複雑な側、つまり OAuth、CLI ログイン、複数アカウント、異なるプロトコル、異なる provider を背後に隠します。前面には OpenAI Chat Completions、OpenAI Responses、Gemini、Claude Messages、Codex 関連エンドポイントのような、比較的なじみのあるインターフェイスを出します。

機能の概要

公式 README とドキュメントを見ると、CLIProxyAPI の主な機能は次の通りです。

CLI モデル向けに OpenAI、Gemini、Claude、Codex 互換 API エンドポイントを提供する。
OAuth ログイン経由で OpenAI Codex と Claude Code を接続する。
ストリーミング、非ストリーミング応答、一部シナリオでの WebSocket をサポートする。
関数呼び出し、ツール呼び出し、マルチモーダル入力をサポートする。
Gemini、OpenAI、Claude の複数アカウントローテーションと負荷分散をサポートする。
Gemini AI Studio API Key をサポートする。
AI Studio Build、Gemini CLI、Claude Code、OpenAI Codex のアカウントプールをサポートする。
設定により OpenRouter などの OpenAI 互換上流へ接続できる。
Go SDK を提供し、自分のサービスへプロキシ機能を組み込める。

この種のプロジェクトで一番価値があるのは、「対応モデル名が多い」ことではありません。アカウントログイン、プロトコル変換、リクエストルーティングという細かく面倒な作業をまとめてくれることです。

向いているユーザー

CLIProxyAPI は次のような人に向いています。

第一に、AI コーディングをかなり使い込んでいる人です。すでに Codex、Claude Code、Gemini CLI を使っていて、それらを Cursor、Cline、RooCode、Amp、社内スクリプト、自作ワークフローへ接続したい場合です。

第二に、複数アカウントプールを持つ人です。複数の Gemini、OpenAI、Claude のログイン状態があり、手動切り替えではなく、自動ローテーション、均等利用、異常アカウントの素早い調査をしたい場合です。

第三に、チーム内ゲートウェイを作る人です。各クライアントが Gemini、Claude、Codex をそれぞれ個別に適配するのではなく、中間層で統一 API として公開したい場合です。

第四に、プロトコルを触るのが好きな人です。Responses、Chat Completions、Claude Messages、Gemini v1beta などのインターフェイスを相互変換したい、あるいは同じクライアントから異なるバックエンドを切り替えたい場合です。

個人がたまに AI に質問するだけ、または公式 App でチャットするだけなら、CLIProxyAPI のデプロイとメンテナンスは重く感じるはずです。

普通の API 中継との違い

普通の API 中継サービスは、おおむね次の形です。

`1`	`クライアント -> 中継 API -> 上流モデル API`

CLIProxyAPI の経路は、むしろこうです。

`1`	`クライアント -> CLIProxyAPI -> CLI / OAuth ログイン状態 / 複数アカウントプール -> モデルサービス`

違いは、API Key の転送だけを扱うわけではないことです。CLI ツール、OAuth アカウント、プロトコル面、モデル別名も扱います。

たとえば Codex や Claude Code のようなツールは、「API Key を1つ渡せば安定して呼べる」伝統的なサービスではありません。CLIProxyAPI はログイン状態と呼び出しロジックを包み込み、外部クライアントが通常の API のようにアクセスできるようにします。

これが魅力であり、同時に複雑さでもあります。

使うときに誤解しやすい点

第一に、統一された /v1/... だけですべてのプロトコル差が消えるとは考えないことです。

CLIProxyAPI のドキュメントでは、特定バックエンドのリクエストとレスポンス形状が必要な場合、provider-specific なパスを優先するよう説明されています。たとえば messages 形式なら /api/provider/{provider}/v1/messages、Gemini のモデルパスなら /api/provider/{provider}/v1beta/models/...、chat-completions 形式なら /api/provider/{provider}/v1/chat/completions です。

統一入口は便利ですが、異なるプロトコルの意味論は消えません。ツール呼び出し、ストリーミング応答、マルチモーダル入力、システムメッセージ処理は、バックエンドごとに細部が変わる可能性があります。

第二に、モデル名は唯一のバックエンドを意味しません。

複数バックエンドが同じクライアント表示用モデル名を公開している場合、パスだけでは実際に推論するバックエンドを固定できないことがあります。厳密に固定したいなら、一意の alias や prefix を使うか、複数バックエンドに同じモデル名を出させないようにします。

第三に、複数アカウントローテーションは無限クォータではありません。

ローテーションはアカウントプールをより均等に使うだけで、上流サービスの本当の制限を回避するものではありません。異常アカウント、クォータ枯渇、リスク制御、OAuth 失効は個別に監視が必要です。

第四に、メンテナンス不要の魔法箱ではありません。

日常ワークフローに入れるなら、設定、ログ、上流アカウント状態、バージョンアップ、クライアント互換性、セキュリティ境界を気にする必要があります。

管理と監視はどうするか

公式 README では、v6.10.0 以降、CLIProxyAPI と CPAMC にはデータ統計機能が同梱されなくなったと説明されています。利用量統計が必要な場合は、独立したプロジェクトを組み合わせます。

CPA Usage Keeper：CLIProxyAPI のデータを同期し、SQLite に保存し、集計 API とダッシュボードを提供する。
CLIProxyAPI Usage Dashboard：ローカル優先の利用量・クォータ看板。アカウント、モデル、時間窓、Codex の残りクォータを表示できる。
CPA-Manager：より完整な管理センター。リクエスト監視、費用見積もり、アカウントプール巡回、異常アカウント特定、整理提案を扱う。

これは、CLIProxyAPI の中心が「プロキシとプロトコル層」であり、一体型の商用管理バックエンドではないことを示しています。チームで使うなら、ログ、監視、アカウントプール管理を最初から考えておく方がよいです。

ほどよい試し方

試すなら、次の順番が安全です。

公式ドキュメントの Quick Start で起動する。
まず Gemini CLI や Codex など、provider を1つだけ接続し、基本リクエストが通ることを確認する。
次にストリーミング応答、ツール呼び出し、マルチモーダル入力のようなリスクの高い機能を試す。
クライアントが実際にどの endpoint を使っているか確認し、プロトコルパスを混ぜない。
最後に複数アカウントローテーション、管理パネル、利用量統計を追加する。

最初から Gemini、Codex、Claude、OpenRouter、複数アカウント、全クライアントを一気に接続しない方がよいです。エラーが出たときに、認証、プロトコル、モデル名、上流アカウントのどれが原因か分からなくなります。

セキュリティ境界も考える

CLIProxyAPI はアカウントログイン状態、API Key、OAuth 関連資格情報、リクエスト内容に触れます。自分のマシンだけで動かすならリスクは比較的制御しやすいですが、インターネットやチーム内ネットワークに公開するなら、認証、アクセス制御、ログのマスキング、ネットワーク分離をきちんと扱う必要があります。

特に管理エンドポイントは、ローカルホストまたは信頼できる内部ネットワークに限定するのが望ましいです。手間を省くために管理インターフェイスを直接公開してはいけません。

まとめ

CLIProxyAPI の価値は、複数の CLI、複数のアカウント、複数のプロトコルに散らばった AI 能力を、プログラム可能な API 層へまとめることにあります。

重度の AI コーディングユーザー、複数アカウントユーザー、チーム内ゲートウェイの用途に向いています。一方で、「すぐ使えて完全にメンテナンス不要」を求める軽量ユーザーにはあまり向きません。

Codex、Claude Code、Gemini CLI を触っていて、それらを自分のクライアントや自動化ワークフローに接続したいなら、CLIProxyAPI は真面目に見る価値があります。ただし一度きりの小道具ではなく、インフラとして扱うべきです。

参考資料：

CodeGraph とは？Claude Code、Codex、Cursor のためのローカルコードマップ

Sat, 23 May 2026 21:09:46 +0800

CodeGraph は、AI コーディングツール向けのローカルコード知識グラフです。プロジェクトを事前にインデックス化し、シンボル関係、コールグラフ、コード構造、ルート関係などを問い合わせ可能なグラフとして整理します。これにより Claude Code、Codex CLI、Cursor、OpenCode、Hermes Agent などは、毎回 grep、glob、Read、探索用サブエージェントに頼ってファイルを探す必要が減ります。

解決しているのは、とても実際的な問題です。AI Agent が大きなコードベースを見るとき、多くのコストはコード変更そのものではなく「コードがどこにあるか」を探すところで発生します。毎回検索し、読み、絞り込むと、token、時間、ツール呼び出しが消費されます。CodeGraph はまずコードベースをローカルの地図にし、Agent が具体的なファイルを読む前にその地図へ問い合わせられるようにします。

解決する主な痛点

小さなプロジェクトでは AI コーディングツールはたいてい問題なく動きます。ファイル数が少なく、検索も速く、読み取りコストも低いからです。しかしプロジェクトが大きくなると、よくある問題が出てきます。

Agent がひとつのモジュールを理解するために、grep、find、ls、Read を何度も呼び出す。
探索用サブエージェントが無関係なファイルを大量に読むが、メインタスクの文脈はあまり明確にならない。
アーキテクチャ質問で、ファイルの場所探しに多くの token を使う。
関数を変更する前に、誰が呼んでいて、その関数が何を呼ぶのか分かりにくい。
Web プロジェクトで、URL ルートと実際のハンドラ関数の関係が直感的でない。

CodeGraph は、この「まず道を探す」作業を前倒ししようとします。インデックスができていれば、Agent は関連シンボル、呼び出し元、呼び出し先、影響範囲、コード片を直接問い合わせられます。

インストール方法

プロジェクトはクロスプラットフォームのインストールスクリプトを提供しており、ユーザーが自分で Node.js を準備する必要はありません。

`1`	`curl -fsSL https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.sh \| sh`

Windows PowerShell では次を使えます。

`1`	`irm https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.ps1 \| iex`

すでに Node 環境がある場合は npm から直接使えます。

`1`	`npx @colbymchenry/codegraph`

またはグローバルにインストールします。

`1`	`npm i -g @colbymchenry/codegraph`

インストーラは Claude Code、Cursor、Codex CLI、opencode、Hermes Agent など、インストール済みの Agent を検出して設定します。対応する MCP server 設定と指示ファイルを書き込み、これらのツールが CodeGraph をいつ呼ぶべきか分かるようにします。

プロジェクトの初期化

インストール後、対象プロジェクトでインデックスを作成します。

1
2

cd your-project
codegraph init -i

このコマンドはプロジェクト単位の知識グラフインデックスを作成します。README によると、プロジェクトに .codegraph/ ディレクトリが存在すれば、Agent は CodeGraph ツールを自動的に使えます。

使わなくなった場合は、グローバル設定を削除できます。

`1`	`codegraph uninstall`

これはインストーラが書き込んだ MCP server 設定、指示、権限を削除します。プロジェクト内の .codegraph/ インデックスは自動削除されません。プロジェクトインデックスを削除するには codegraph uninit を使います。

Agent にとってなぜ役立つのか

Claude Code、Codex CLI、Cursor のようなツールは、コードベースを理解する前に探索を行いがちです。ファイルを探し、入口を読み、参照を調べ、呼び出しチェーンを追います。人間にとっては「プロジェクトを見て回る」作業ですが、モデルにとってはツール呼び出しとコンテキスト消費の連続です。

CodeGraph はこれをインデックス問い合わせに変えます。Agent はまず codegraph_context で関連する入口、シンボル、コード片を見つけ、その後 codegraph_explore などで必要な内容を読みます。利点は次のとおりです。

無関係なファイルを読む量が減る。
検索ツールの呼び出しが減る。
本当に関係するコードに早くたどり着ける。
変更前に影響範囲を見やすくなる。
大規模リポジトリのアーキテクチャ質問に答えやすくなる。

README のベンチマークでは、7 つの実際のオープンソースリポジトリで、CodeGraph ありとなしを比較しています。平均ではコスト、token、速度、ツール呼び出しの面で改善が見られます。具体的な数字はプロジェクト規模、言語、質問の種類、Agent の使い方によって変わりますが、大きなリポジトリほど事前インデックスの価値が出やすいことは明確です。

主な機能

1. スマートなコンテキスト構築

ひとつのツール呼び出しで、入口、関連シンボル、コード片を返せます。Agent が探索タスクを大量に投げてから絞り込む場面を減らせます。アーキテクチャ理解、モジュール特定、機能入口の分析に役立ちます。

2. 全文検索

CodeGraph は FTS5 を使って全文検索を行い、コードベース全体から名前やテキストを高速に探せます。すべての grep を置き換えるものではありませんが、Agent にとってより構造化された最初の探索地点になります。

3. 影響分析

関数、クラス、メソッド、ルートを変更する前に、callers、callees、影響範囲を問い合わせられます。リファクタリング、バグ修正、古いコード削除では、上流や下流の呼び出しを漏らすことが大きなリスクなので特に有用です。

4. 自動更新

README によると、CodeGraph は FSEvents、inotify、ReadDirectoryChangesW などのネイティブファイルシステムイベントと debounce auto-sync を使います。つまり、ローカルコードの変更に合わせてインデックスが自動更新され、ファイルを変更するたびに手動で再構築する必要はありません。

5. 多言語対応

プロジェクトは 19 以上の言語をサポートするとしています。TypeScript、JavaScript、Python、Go、Rust、Java、C#、PHP、Ruby、C、C++、Swift、Kotlin、Dart、Lua、Luau、Svelte、Liquid、Pascal / Delphi などが含まれます。

そのため、単一言語だけでなく、多言語リポジトリやフルスタックプロジェクトにも向いています。

6. Web ルート認識

CodeGraph は、多くの Web フレームワークのルートファイルやルート宣言も認識し、URL pattern とハンドラ関数を接続します。README では Django、Flask、FastAPI、Express、NestJS、Laravel、Rails、Spring、Gin、Axum、ASP.NET、Vapor、React Router、SvelteKit などに触れています。

これは実用的です。多くの Web プロジェクトの本当の入口は、明確な main 関数ではなく、ルート、controller、handler、view、resolver です。Agent が URL と処理関数の関係を先に知っていれば、業務フローの理解がかなり速くなります。

ローカル優先の設計

CodeGraph は 100% local を強調しています。API key は不要で、外部サービスにも依存しません。インデックスデータはローカル SQLite データベースに保存されます。

企業プロジェクト、プライベートリポジトリ、機密コードでは、この設計が重要です。AI ツールをコードベースに接続するとき、心配されるのは「コードを見つけられるか」だけではなく、「コード構造やインデックスが外部へ送られないか」です。CodeGraph はローカル構築、ローカル問い合わせ、ローカルで Agent に提供する設計です。

もちろんローカルである以上、ディスク容量、インデックス時間、ファイル監視、プロジェクト規模も考える必要があります。非常に大きなリポジトリでは、初回初期化やその後の同期にもリソースが必要です。

向いている場面

CodeGraph は次のような場面に向いています。

大規模コードベースで、アーキテクチャや呼び出しチェーンの質問が多い。
Claude Code、Codex CLI、Cursor などの Agent でコード理解や変更を行う。
Agent があちこちのファイルを読み、広く検索し、探索を繰り返す状況を減らしたい。
変更前に影響範囲を分析したい。
Web プロジェクトのルートが複雑で、URL からハンドラを素早く見つけたい。
チームとして AI Agent に安定したローカルプロジェクトインデックスを与えたい。

数十ファイル程度の小さなプロジェクトなら、普通の検索で十分かもしれません。CodeGraph が最も価値を出すのは、中規模から大規模のコードベースで、Agent に探索をよくさせる場面です。

使うときの注意点

第一に、CodeGraph はコードレビューやテストの代替ではありません。Agent が関連コードを早く見つける助けにはなりますが、変更が必ず正しいことは保証しません。

第二に、インデックス品質が結果に影響します。複雑な構造、大量の生成コード、混在言語、除外されていない build 生成物があると、インデックスがノイズを含みやすくなります。使う前に .gitignore、プロジェクト構成、インデックス範囲を確認したほうがよいでしょう。

第三に、MCP 設定と Agent 指示が重要です。README でも、CodeGraph は正しく問い合わせられたときに効果があると説明しています。Agent がそれを無視して大量のファイルを直接読むなら、事前インデックスは追加コストになります。

第四に、ローカルツールであっても権限には注意が必要です。インストーラは Agent 設定と権限リストを書き込みます。チーム環境では、これらの設定をまとめて確認するほうが安全です。

まとめ

CodeGraph の価値は、AI Agent にローカルのコード地図を渡すことだと理解できます。モデルを賢くするのではなく、モデルが迷いにくくなるようにします。

Claude Code、Codex CLI、Cursor などが大規模リポジトリに向き合うとき、コンテキストを多く消費するのは探索です。CodeGraph は事前インデックス化されたシンボル関係、コールグラフ、ルートグラフ、全文検索によって「コードを探す」段階を先に済ませ、Agent が理解と変更により多くの予算を使えるようにします。

実際のプロジェクトで AI コーディングツールを使っていて、「たくさんファイルを読んだのに要点を見つけられない」場面が多いなら、CodeGraph は試す価値があります。これは AI コーディングツールの重要な方向性を示しています。より強いモデルだけでなく、そのモデルにより良いローカルコードコンテキストを与えることも必要です。

参考資料：

GitHub プロジェクト：https://github.com/colbymchenry/codegraph

Claude Code にもプラグインマーケットが登場：何を入れられるのか、どう入れるのか、何に注意するのか

Sat, 23 May 2026 19:03:30 +0800

anthropics/claude-plugins-official は、Anthropic が管理する Claude Code の公式プラグインディレクトリです。これは単なるコードリポジトリではなく、Claude Code のプラグインシステムから直接利用できる marketplace であり、Anthropic が保守または選定した Claude Code プラグインを集めています。

このリポジトリが重要なのは、Claude Code が「AI コーディング用のコマンドラインツール」から「拡張可能な開発環境」へ向かっていることを示しているからです。プラグインは Skills、Agents、Hooks、MCP servers、LSP servers、バックグラウンドモニタ、デフォルト設定をまとめてパッケージ化し、チームやコミュニティが統一された形で配布できるようにします。

このリポジトリは何か

README の説明は明快です。これは高品質な Claude Code プラグインの curated directory です。

ディレクトリは主に 2 つに分かれています。

/plugins：Anthropic 社内で開発・保守されるプラグイン。
/external_plugins：パートナーやコミュニティによるサードパーティプラグイン。

つまり、公式機能と選定済みの外部エコシステム入口の両方が含まれています。一般ユーザーにとっては、Claude Code の /plugin システムからプラグインを見つけてインストールできることが直接的な価値です。開発者にとっては、Claude Code のプラグイン形式とエコシステムの方向性を観察できる場所です。

プラグインのインストール方法

README ではシンプルなインストール方法が示されています。Claude Code のプラグインシステムから直接インストールできます。

`1`	`/plugin install {plugin-name}@claude-plugins-official`

Claude Code 内のプラグイン発見画面から探すこともできます。

`1`	`/plugin > Discover`

ここで重要なのは @claude-plugins-official です。これは公式プラグインディレクトリの marketplace を指します。Claude Code ドキュメントによると、claude-plugins-official は Anthropic が管理する公式 marketplace で、Claude Code のインストール環境でデフォルトで利用できます。

プラグインの構造

リポジトリ README では標準的なプラグイン構造が示されています。

plugin-name/
├── .claude-plugin/
│   └── plugin.json
├── .mcp.json
├── commands/
├── agents/
├── skills/
└── README.md

.claude-plugin/plugin.json はプラグインのメタデータファイルで、通常は名前、説明、バージョン、作者などを宣言します。その他のディレクトリは必要に応じて存在します。

skills/：Claude が自動的に呼び出せるスキル説明。
commands/：slash commands。
agents/：カスタム agent 定義。
hooks/：イベントに反応するロジック。
.mcp.json：MCP server 設定。
.lsp.json：言語サーバー設定。
monitors/：バックグラウンドモニタ設定。
settings.json：プラグインに付属するデフォルト設定。

つまり Claude Code プラグインは単一種類の拡張ではなく、パッケージ形式です。小さなコマンドだけのこともあれば、特定の技術スタック向けのワークフロー全体になることもあります。

公式ディレクトリにある主な方向性

/plugins ディレクトリを見ると、公式保守のプラグインは多くの開発場面をカバーしています。

LSP 系プラグイン：typescript-lsp、pyright-lsp、rust-analyzer-lsp、gopls-lsp、clangd-lsp、csharp-lsp、jdtls-lsp、kotlin-lsp、lua-lsp、php-lsp、ruby-lsp、swift-lsp。
開発ワークフロー：code-review、feature-dev、code-modernization、code-simplifier、commit-commands、pr-review-toolkit。
Claude Code 設定とプラグイン開発：claude-code-setup、claude-md-management、plugin-dev、skill-creator、mcp-server-dev。
出力スタイルと専門機能：explanatory-output-style、learning-output-style、security-guidance、session-report、math-olympiad。

/external_plugins では、github、gitlab、linear、asana、firebase、playwright、terraform、context7、serena、telegram、discord など、サードパーティツールやサービスとの接続が見えます。

これらのプラグインは、Claude Code が単にファイルを編集するだけでなく、コードインテリジェンス、プロジェクト管理、クラウドサービス、テスト、インフラ、チーム協業ツールに接続しようとしていることを示しています。

なぜプラグインシステムが重要なのか

以前から Claude Code のカスタマイズは、プロジェクト内の .claude/ ディレクトリに commands、agents、skills、hooks として置けました。この方法は個人や単一プロジェクトには向いていますが、複数プロジェクトでの再利用やチーム内での統一配布には不向きです。

プラグインが解決するのは、再利用と配布の問題です。

同じ設定を複数プロジェクトにインストールできる。
コマンドやスキルに名前空間があり、衝突を減らせる。
marketplace 経由で公開や更新ができる。
チームのベストプラクティスを標準プラグインとしてまとめられる。
コミュニティが特定のフレームワーク、言語、サービス向け拡張を保守できる。

これは VS Code 拡張、JetBrains プラグイン、ブラウザ拡張に近い考え方です。安定したプラグインエコシステムを持ち始めたツールは、単一製品ではなくプラットフォームになり始めます。

開発者にとっての使い道

Claude Code ユーザーにとって、このリポジトリの最も実用的な使い方はプラグイン探しです。たとえば TypeScript、Python、Rust、Go の LSP が必要なら、まず公式ディレクトリに対応プラグインがあるか確認できます。PR review、commit、コードのモダナイズなどのワークフローも、公式プラグインから試すのがよい入口になります。

プラグイン開発者にとっては、このリポジトリはサンプル集に近いものです。ディレクトリ構成、plugin.json の書き方、README の説明、Anthropic が skills、agents、MCP、LSP、hooks をどう組み合わせているかを参考にできます。

Claude Code ドキュメントも明確に勧めています。単一プロジェクトのカスタマイズなら .claude/ でよく、チーム共有、複数プロジェクトでの再利用、バージョン化された配布、marketplace への公開が必要になったらプラグインにするべきです。

セキュリティ境界は無視できない

リポジトリ README は冒頭で、プラグインをインストール、更新、使用する前に信頼できるか確認するよう注意しています。理由は単純です。プラグインには MCP server、ファイル、スクリプト、その他のソフトウェアが含まれる可能性があります。Anthropic がディレクトリを管理しているからといって、すべてのプラグインがあなたのローカル環境で期待どおりに動くとは限りません。

実際に使うときは、少なくとも次を確認したほうがよいでしょう。

インストール前にプラグインのホームページと README を読む。
.mcp.json、hooks、実行可能スクリプト、バックグラウンドモニタが含まれていないか確認する。
アカウント、コードリポジトリ、チャットツール、クラウドサービスにアクセスするプラグインは特に慎重に扱う。
重要なプロジェクトで有効化する前に、テスト用リポジトリで検証する。
チーム環境では、プラグインの提供元とバージョンを一元的に確認する。

AI コーディングプラグインの権限は、普通のエディタテーマよりはるかに大きくなりがちです。プロジェクトファイルを読んだり、外部サービスを呼び出したり、ローカルコマンドを起動したり、コミットやデプロイの流れに影響したりする可能性があります。そのため信頼境界は「小さなツールを入れる」より厳しく考えるべきです。

コミュニティ marketplace との関係

Claude Code ドキュメントによると、Anthropic は 2 つの公開プラグイン marketplace を管理しています。

claude-plugins-official：Anthropic が管理する curated プラグイン集合。
claude-community：サードパーティ投稿がレビューを経て入るコミュニティプラグインディレクトリ。

両者の役割は異なります。コミュニティプラグインは提出フォームから review に進めますが、公式ディレクトリは Anthropic が独自に収録を決めるもので、一般の申請プロセスはありません。つまり claude-plugins-official は公式の厳選ディレクトリに近く、claude-community はより開かれたコミュニティディレクトリです。

まとめ

anthropics/claude-plugins-official の意味は、単に GitHub リポジトリがひとつ増えたことではありません。Claude Code の拡張機構がプラットフォーム化しつつあることを示しています。Skills、Agents、Hooks、MCP、LSP、バックグラウンドモニタ、デフォルト設定を、パッケージ化、インストール、更新、配布できるようになっています。

個人開発者にとっては、公式プラグインディレクトリが Claude Code 設定の手間を下げます。チームにとっては、内部フローを標準化する道になります。プラグイン開発者にとっては、Anthropic が認めるプラグイン構造とエコシステムの方向性を示す資料になります。

今後見るべきなのは、単体のプラグインだけではありません。公式厳選、コミュニティプラグイン、チーム内 private marketplace、主要言語・フレームワーク・SaaS 向けの専門拡張という層が安定してできるかです。この流れが進めば、Claude Code は単なるコマンドラインアシスタントではなく、編成可能な AI 開発プラットフォームに近づいていきます。

参考資料：

GitHub プロジェクト：https://github.com/anthropics/claude-plugins-official
Claude Code プラグインドキュメント：https://code.claude.com/docs/en/plugins

GraphifyがClaude Code最大の制約を解く：コードベースをAIが検索できる知識グラフへ

Thu, 21 May 2026 08:02:32 +0800

safishamsi/graphify は、AIコーディングアシスタント向けの知識グラフツールです。目的は明快です。プロジェクトディレクトリ内のコード、文書、SQL schema、スクリプト、論文、画像、動画、音声を検索可能な知識グラフに整理し、AIアシスタントが grep、全文読み込み、その場限りの検索だけに頼らずにプロジェクトを理解できるようにします。

プロジェクトURL：safishamsi/graphify

この記事の整理時点で、GitHubページには約50.2k stars、5.4k forksが表示されており、ライセンスはMITです。READMEでは、AIコーディングアシスタント内で /graphify と入力すると、プロジェクト全体を検索可能な知識グラフにマッピングすると説明されています。

解決する中核問題

AIコーディングアシスタントはますます強くなっていますが、実際のコードベースではまだよく次の問題に直面します。

主要モジュール同士がどうつながるのかわからない。
多くのファイルを読んでも、全体のアーキテクチャマップができない。
検索でテキストは見つかるが、上流・下流の依存関係がわからない。
コード、database schema、ドキュメント、インフラ設定が別々の場所に分散している。
チーム開発では、人によってプロジェクト構造の理解が異なる。

Graphifyが作ろうとしているのは、プロジェクトの「記憶層」です。コードエンティティ、文書の概念、データベース表、設定、設計メモ、ファイル間の関係をつなげ、AIアシスタントが毎回ゼロからファイルを読むのではなく、グラフを問い合わせられるようにします。

最小構成での使い方

Graphifyの最小利用はとても簡単です。インストール後、AIコーディングアシスタント内で次を入力します。

`1`	`/graphify .`

PowerShellでは先頭の / がパス区切りとして扱われるため、Windows PowerShellでは次のようにします。

`1`	`graphify .`

実行後、graphify-out/ ディレクトリが生成され、主なファイルは次の三つです。

graphify-out/
├── graph.html
├── GRAPH_REPORT.md
└── graph.json

それぞれの役割は異なります。

graph.html：ブラウザーで開けるインタラクティブグラフ。ノードクリック、フィルター、検索ができる。
GRAPH_REPORT.md：プロジェクトのハイライト、重要概念、意外な接続、推奨質問。
graph.json：完全なグラフ。後から再読み込みせずに直接問い合わせられる。

Mermaidの呼び出しフロー図を含む読みやすいアーキテクチャページを作るには、次を実行します。

`1`	`graphify export callflow-html`

インストールと対応プラットフォーム

GraphifyのPyPIパッケージ名は graphifyy です。y が二つある点に注意してください。READMEでは、PyPI上の他の graphify* パッケージはこのプロジェクトと無関係だと明記されています。ただしCLIコマンド名は graphify のままです。

推奨インストール方法は次の通りです。

`1`	`uv tool install graphifyy`

代替方法もあります。

1
2

pipx install graphifyy
pip install graphifyy

インストール後、AIアシスタントに登録します。

`1`	`graphify install`

対応プラットフォームは多く、Claude Code、Codex、OpenCode、GitHub Copilot CLI、VS Code Copilot Chat、Aider、Cursor、Gemini CLI、Kimi Code、Kiro、Google Antigravityなどがあります。プラットフォームごとに次のようなコマンドを使えます。

graphify install --platform codex
graphify install --platform gemini
graphify cursor install
graphify antigravity install

Codexユーザーは、~/.codex/config.toml の [features] に次も追加する必要があります。

`1`	`multi_agent = true`

READMEでは、Codexは /graphify ではなく $graphify を使うとも説明されています。

どんなファイルを処理できるか

Graphifyは幅広い入力タイプを扱えます。

コードでは31言語をサポートします。Python、TypeScript、JavaScript、Go、Rust、Java、C/C++、Ruby、C#、Kotlin、Scala、PHP、Swift、Lua、Zig、PowerShell、SQL、Shell、JSONなどです。

文書では次をサポートします。

.md
.mdx
.qmd
.html
.txt
.rst
.yaml
.yml

オプション依存関係でさらに拡張できます。

pip install "graphifyy[pdf]"
pip install "graphifyy[office]"
pip install "graphifyy[video]"
pip install "graphifyy[mcp]"
pip install "graphifyy[neo4j]"
pip install "graphifyy[sql]"
pip install "graphifyy[all]"

pdf はPDF抽出、office は .docx と .xlsx、video は動画と音声の文字起こし、mcp はMCP stdio server、neo4j はNeo4jへのpush、sql はSQL schema抽出に使います。

生成されるレポートの価値

GRAPH_REPORT.md は普通の要約ではありません。プロジェクト内でAIアシスタントが注目すべき関係を抽出します。

READMEで挙げられている内容には次のようなものがあります。

God nodes：プロジェクト内で最も多く接続されている中核概念。
Surprising connections：ファイルやモジュールをまたぐ意外な接続。
The why：コメント、docstring、設計文書から抽出された設計理由。
Suggested questions：グラフが特に答えやすい質問。
Confidence tags：関係が EXTRACTED、INFERRED、AMBIGUOUS としてラベル付けされる。

これは重要です。通常の検索は「この単語がどこに出るか」を教えます。一方、グラフは「この概念がどのモジュール、設定、表、文書と関係するか」を答えられます。大規模コードベースでは、これは単純な全文検索よりアーキテクチャ理解に近いものです。

よく使うコマンド

Graphifyの主なコマンドは次の通りです。

/graphify .
/graphify ./docs --update
/graphify . --cluster-only
/graphify . --no-viz
/graphify . --wiki
graphify export callflow-html
/graphify query "what connects auth to the database?"
/graphify path "UserService" "DatabasePool"
/graphify explain "RateLimiter"

論文や動画をグラフへ追加することもできます。

1
2

/graphify add https://arxiv.org/abs/1706.03762
/graphify add <youtube-url>

PR分析補助には次のコマンドも使えます。

graphify prs
graphify prs 42
graphify prs --triage
graphify prs --conflicts

これらはコードレビューに向いています。PRがどのグラフコミュニティに影響するか、他のPRと衝突リスクがあるか、どのreview queueを優先すべきかを確認できます。

MCP、Neo4j、CIとの関係

GraphifyはHTMLグラフを生成するだけではありません。グラフをAIアシスタントへ繰り返し呼び出せる形で公開できます。

たとえばMCP serverを起動できます。

`1`	`python -m graphify.serve graphify-out/graph.json`

MCP serverは query_graph、get_node、get_neighbors、shortest_path、list_prs、get_pr_impact、triage_prs などを提供します。

Neo4jへのエクスポートやpushにも対応します。

1
2

/graphify ./raw --neo4j
/graphify ./raw --neo4j-push bolt://localhost:7687

チーム開発では、READMEは graphify-out/ をgitにコミットすることを提案しています。これにより、チーム全員が同じプロジェクトマップから始められます。次も実行できます。

`1`	`graphify hook install`

これにより、git commit後にグラフが自動再構築され、merge driverも設定されます。複数人が並行してコミットしても、graph.json に競合マーカーが残りにくくなります。

プライバシーとコスト

GraphifyのREADMEはプライバシー境界を比較的明確に説明しています。

コードファイルはtree-sitterでローカル解析され、API呼び出しは発生しません。動画と音声はfaster-whisperでローカル文字起こしできます。文書、PDF、画像などの意味抽出は、利用しているAIアシスタントのモデルAPIを通ります。

headless graphify extract を使う場合、次の環境変数が必要になることがあります。

ANTHROPIC_API_KEY
GEMINI_API_KEY
GOOGLE_API_KEY
OPENAI_API_KEY
DEEPSEEK_API_KEY
MOONSHOT_API_KEY
OLLAMA_BASE_URL

ローカルOllama、AWS Bedrock、Claude Code CLIなどもbackendとして使えます。READMEにはtelemetry、usage tracking、analyticsがないことも記載されています。

実際に使うときは、コードのローカル解析がすべての内容が外へ出ないことを意味するわけではない点に注意が必要です。文書、PDF、画像、クラウドモデルが関わる場合は、backend、API key、企業コンプライアンス、データ境界を確認する必要があります。

向いている場面

Graphifyは次のようなユーザーに向いています。

Claude Code、Codex、Cursor、Gemini CLIにプロジェクト構造をより理解させたい開発者。
大規模で見慣れないコードベースを素早く理解したい人。
コード、SQL schema、ドキュメント、設定をまとめて分析したいチーム。
アーキテクチャレビュー、PR review、リファクタリング影響分析を行う人。
プロジェクト知識をMCPツールとしてAgentに公開したい人。
チームのために「プロジェクトマップ」を残したい技術リーダー。

すべてのプロジェクトに必要なわけではありません。小さなスクリプト、一回限りのdemo、非常に単純なリポジトリでは、通常の検索とREADMEで十分かもしれません。Graphifyの価値は、モジュールが多く、文書が多く、チーム開発が多く、AIアシスタントが頻繁に関与する大きなプロジェクトでより出やすくなります。

まとめ

Graphifyの意味は、AIコーディングアシスタントのコンテキストを「一時的なファイル読み取り」から「長期的に検索可能なプロジェクト知識グラフ」へ進めることです。

開発者にとって、GraphifyはIDE、検索、LSPの代替ではありません。AIアシスタントに構造化された記憶層を追加します。どのモジュールが重要か、どの概念が強くつながるか、どの文書が設計理由を説明しているか、あるPRがどのコミュニティに影響するかを扱えます。Codex、Claude Code、Gemini CLI、AntigravityのようなAgentツールが普及するほど、この種のプロジェクトグラフ層はますます有用になります。

参考：

GitHub：safishamsi/graphify

Open Design解説：Claude CodeとCodexをAIデザインツールに変える

Mon, 18 May 2026 18:57:16 +0800

Open Designは、nexu-ioが公開しているオープンソースのAIデザインプロジェクトだ。local-firstで、Claude DesignやFigmaの代替方向を目指している。

解決しようとしている問題は明確だ。Claude Designは、大規模モデルがデザイン成果物を直接生成できることを示した。しかしその能力が、クローズドで、クラウド限定で、単一モデルに縛られた製品の中だけにあるなら、ユーザーは自己ホスト、自分のAgent接続、モデル差し替え、私有デザインシステムの蓄積、ローカルワークフローへの組み込みが難しくなる。

Open Designは新しい基盤モデルを作るのではない。あなたのPCにすでにあるcoding-agent CLIを、デザインワークスペースへ接続する。Claude Code、Codex、Cursor Agent、Gemini CLI、OpenCode、Qwen、Copilot CLI、Kimi、DeepSeek TUIなどが、デザインエンジンとして使える。

Open Designとは何か

Open Designは3つの要素の組み合わせとして理解できる。

会話、プレビュー、プロジェクト管理、エクスポートを行うWeb UI。
Agentのスケジューリング、ファイル管理、プロジェクト保存、API提供を行うローカルdaemon。
Agentの出力を、単なるAIページではなくデザイン成果物へ近づけるためのSkills、Design Systems、テンプレート。

ユーザーが要望を入力すると、Open Designは一文をそのままモデルへ投げるだけではない。まずデザインbriefを補足させ、用途と方向性を選ばせる。そのうえで、プロジェクトメタデータ、現在のデザインシステム、Skillファイル、テンプレート、チェックリストをAgentへ注入する。Agentは実際のプロジェクトフォルダでファイルを読み書きし、最後にサンドボックスiframeでプレビューできるartifactを生成する。

そのため、単発のWebページ生成器ではなく、AIデザインワークフローに近い。

普通のAI Web生成と何が違うのか

多くのAIツールはHTMLページを生成できる。しかしOpen Designの焦点は「モデルにページを書かせる」ことではない。「デザインプロセスに沿って、プレビューでき、エクスポートでき、反復できる成果物を届ける」ことだ。

いくつかの設計方針がある。

生成前に質問する。新しいdesign briefでは、まず対話式のquestion formが出て、対象者、トーン、ブランド文脈、制約、視覚方向を固める。
Skillsはファイルであり、ブラックボックスプラグインではない。各Skillは SKILL.md、assets/、references/ で構成され、読めるし、差し替えられるし、拡張できる。
Design SystemsはMarkdownであり、固定テーマJSONではない。色、タイポグラフィ、余白、コンポーネント、モーション、ブランドボイス、避けるべきパターンを DESIGN.md に書ける。
Agentは実際のプロジェクトディレクトリで作業する。テンプレートを読み、ファイルを書き、画像を生成し、.pptx、.pdf、.zip などを出力できる。
成果物はサンドボックスiframeでプレビューされ、制御されていないコードを直接実行するリスクを減らす。

この構造の狙いは、AIを、ルール、素材、チェックリストを持つデザイン協力者に近づけることだ。

対応するAgent

Open Designの特徴の一つは、Agentをランタイムとして扱い、特定のモデル企業へ固定しない点だ。

READMEには、Claude Code、Codex CLI、Devin for Terminal、Cursor Agent、Gemini CLI、OpenCode、Qwen Code、Qoder CLI、GitHub Copilot CLI、Hermes、Kimi、Pi、Kiro、Kilo、Mistral Vibe、DeepSeek TUIなどが挙げられている。これらのCLIを PATH から自動検出し、ユーザーが切り替えられる。

適切なローカルCLIがない場合は、OpenAI-compatibleなBYOK proxyも使える。baseUrl、apiKey、モデル名を入力すると、daemonがストリーミング出力を同じチャットストリームへ正規化する。

この設計には利点がある。

単一モデルにロックされない。
ユーザーがすでにインストール・設定したAgentを再利用できる。
ローカルファイルの読み書きをdaemonが管理し、権限境界がわかりやすい。
企業や上級ユーザーは、自社モデルやAPIプロバイダーを接続しやすい。

SkillsとDesign Systemsが中心資産

Open Designには多くのSkillsとDesign Systemsが同梱されている。READMEによれば、組み込みSkillsはWebプロトタイプ、SaaS landing page、dashboard、mobile app、gamified app、SNS carousel、雑誌ポスター、PPT、週報、財務レポート、HR onboarding、invoice、kanban、OKRなどをカバーする。

Design Systemsは、Agentにブランドレベルの視覚制約を与える。リポジトリ紹介では、Linear、Stripe、Vercel、Airbnb、Tesla、Notion、Apple、Anthropic、Cursor、Supabase、Figma、小紅書などのデザインシステムが挙げられている。

関係はこう考えるとよい。

Skillは「今回どんな種類の成果物を作るか」を決める。
Design Systemは「その成果物がどんなブランドスタイルになるべきか」を決める。

この2層がないと、AIは見慣れているが判断のない汎用ページを生成しやすい。SkillsとDesign Systemsがあれば、モデルは少なくとも明確なタスク境界、視覚参照、チェックルールを持つ。

何を生成できるのか

Open DesignはWebプロトタイプだけのツールではない。

READMEによると、web、desktop、mobile prototypes、slides、images、videos、HyperFramesなどを扱い、HTML、PDF、PPTX、ZIP、Markdownへのエクスポートにも対応する。メディア生成では、ポスター、アバター、インフォグラフィック、地図イラスト、短い動画、HTMLからMP4へのモーショングラフィックなども同じデザインループに含まれる。

利用場面は広い。

スタートアップチームがpitch deckを素早く作る。
プロダクトチームがlanding pageや機能プロトタイプを生成する。
運用チームがキャンペーンページ、SNS画像、週報を作る。
デザイナーがmoodboard、視覚方向、初期layoutを作る。
開発者が要求を動くフロントエンドartifactへ変える。

価値は「1ページを生成する」だけではない。複数のコンテンツ形態を同じAgentワークフローへ入れることにある。

local-firstとは何か

Open Designはlocal-firstを強調する。すべてを遠隔SaaSバックエンドへ渡すのではなく、ローカルでdaemonとプロジェクトワークスペースを動かす。

READMEで説明されているアーキテクチャはおおむね次の通り。

フロントエンドはNext.js / React / TypeScript。
ローカルdaemonはNode、Express、SQLite、SSEを使う。
プロジェクト、セッション、メッセージ、tab、テンプレートなどはローカルSQLiteと .od/projects/<id>/ に保存される。
Agentは child_process.spawn で起動し、プロジェクトartifactフォルダで読み書きする。
プレビューはサンドボックスiframeでレンダリングされる。
エクスポートはHTML、PDF、PPTX、ZIP、Markdownを含む。

この構造は、設計成果物を自分のマシンに残し、ローカルAgentを接続し、API keyを管理し、私有ワークスペースを維持したいユーザーに向いている。

ただしlocal-firstは完全オフラインを意味しない。実際の生成は利用するAgentとモデルに依存する。クラウドモデルAPIを使えば、内容はそのプロバイダーへ送られる。より正確には、Open Designはワークスペース、スケジューリング、ファイル、プレビューをローカル制御へ戻し、モデル層はユーザーに選ばせる。

Claude Design / Figmaとの関係

Open DesignはREADMEで、Claude Design / Figmaのオープンソース代替方向と説明している。ただし、伝統的なFigmaクローンではない。

Figmaは、デザイナーが手動編集、協業、デザイン稿の納品を行うプロ向けツールだ。Open Designはよりagent-nativeで、ユーザーが自然言語、フォーム、Skills、デザインシステムを通じてAgentを動かし、実行可能なartifactを出力する。

組み合わせている要素は次のようなものだ。

Claude Designのartifact-first体験。
Figma的なデザインシステム意識。
Claude Code / CodexのようなAgentのファイル読み書きと実行能力。
ローカルdaemonによるプロジェクト管理とサンドボックスプレビュー。

そのため、プロデザイナーの全工程を置き換えるとは限らないが、「アイデアからプレビュー可能なプロトタイプ」への高速ルートとしては向いている。

向いているユーザー

Open Designが向いているのは次のような人だ。

Claude Code、Codex、Cursor、Gemini CLIなどのAgentをすでに使っている開発者。
AIデザイン成果物をローカルプロジェクトディレクトリで管理したい人。
Webプロトタイプ、PPT、ポスター、運用素材を素早く作りたいスタートアップチーム。
Skills、Design Systems、プロンプトスタックをカスタマイズしたい上級ユーザー。
単一モデルや単一クラウド製品に縛られたくないチーム。

あまり向いていないのは次のような人だ。

Webページを開き、一文を入力し、すぐ画像をダウンロードしたい軽量ユーザー。
Node、pnpm、daemon、CLI、ローカル設定に触りたくない人。
成熟した共同編集、デザインレビュー、ベクター編集を必要とする本格的なFigmaワークフロー。

言い換えると、Open Designは万人向けの軽量デザインSaaSというより、Agentユーザーと技術寄りのデザインチーム向けのツールだ。

注意点

Open DesignのREADMEには 0.8.0-preview とあり、プロジェクトがまだ高速に進化していることが示されている。活発さは魅力だが、API、データディレクトリ、デスクトップ版移行、Skills構造、エクスポートフローは変わる可能性がある。

使う前に注意したい点は次の通り。

安定した企業向けデザインプラットフォームとして扱わない。
重要な資料を入れる前に、テストプロジェクトでワークフローを試す。
.od/ データを移行する場合は先にバックアップし、daemonとデスクトップアプリを停止する。
BYOK利用時はAPI key、プロキシURL、ローカル私有ネットワークアクセスのリスクに注意する。
生成されたデザインは、人間がレビューする。特にブランド、著作権、コピー、視覚一貫性は確認が必要だ。

オープンソースの利点は、検査でき、変更でき、貢献できることだ。その代わり、ある程度のエンジニアリング摩擦を受け入れる必要がある。

まとめ

Open Designの見どころは、単に「オープンソース版Claude Design」であることではない。本当に面白いのは、Agent CLI、Skills、Design Systems、ローカルdaemon、サンドボックスプレビューを一つのデザインワークフローにまとめている点だ。

設計生成を単発promptから、より構造化された流れへ押し上げている。質問し、方向を選び、デザインシステムを読み込み、Skillを読み、実ファイルへ書き、artifactをプレビューし、結果をエクスポートする。

すでにClaude Code、Codex、Cursorでコード作業をしているなら、Open Designは注目に値する。AIが一枚の画像を描くだけでなく、ローカルプロジェクト空間で、デザインシステムとタスクスキルに沿って、継続的に反復できるデザイン成果物を生成するという新しい製品形態を示している。

参考資料

nexu-io/open-design GitHubリポジトリ

Claude CodeでTokenを節約する：モデル、MCP、CLAUDE.md、Skillsがキャッシュに与える影響

Mon, 18 May 2026 18:30:24 +0800

Claude Codeの長いタスクでは、Prompt Cacheの命中率がコストと速度に直接影響する。キャッシュでTokenを節約できることは知られているが、どの操作で突然キャッシュが外れるのかは見落とされがちだ。

毎回のリクエストは、左から右へ流れるコンテキストの鎖として考えるとわかりやすい。

`1`	`tools -> system -> CLAUDE.md / skills -> messages`

左にある内容ほど安定させるべきで、キャッシュ効果も大きい。左側が変わると、その後ろのキャッシュも再計算されやすい。逆に右側の変化は影響範囲が小さい。

つまりClaude CodeのPrompt Cache最適化は、勘ではない。タスク開始前にモデル、MCP、Skills、CLAUDE.mdなどの基本コンテキストを準備し、開始後はできるだけ変えないことが重要だ。

Prompt Cacheは文字列そのものをキャッシュしない

Prompt Cacheは、プロンプト文字列をそのまま保存するだけの仕組みではない。Transformerモデルでは、前方のコンテキストを注意層で計算したKey/Value状態、つまりKV cacheが重要になる。

これは2つのことを意味する。

前方のコンテキストが安定していれば、後続リクエストで一部の計算結果を再利用できる。
モデル、ツール定義、システムプロンプト、前方メッセージが変わると、以前のキャッシュを再利用できないことがある。

Anthropic公式ドキュメントも、失効階層を tools -> system -> messages と整理している。ツール定義の変更は全体のキャッシュに影響し、system層の変更はsystemとmessagesに影響し、messages層の変更は主にメッセージキャッシュに影響する。

Claude Codeではさらに CLAUDE.md、Skills、MCP、プラグイン、subagentなどが関わるため、実際の利用ではキャッシュ失効点を踏みやすい。

キャッシュを壊す要因1：途中でモデルを切り替える

モデル切り替えは最も影響が大きい操作の一つだ。

Prompt Cacheはモデルごとに分離される。Opus、Sonnet、Haikuは構造や重みが異なるため、同じテキストから計算したKV cacheも共有できない。Opusで長いコンテキストを作ったあとSonnetへ切り替えても、SonnetはOpusのキャッシュを再利用できない。

そのため、節約のつもりで途中から安いモデルへ切り替えると、かえってそれまでのキャッシュが無駄になることがある。本来cache read価格で読めたコンテキストが、再度書き込みと計算の対象になる。

安定したやり方は次の通り。

メイン会話ではモデルを固定する。
安いモデルで処理したい支線タスクはsubagentに分離する。
支線エージェントに検索、探索、整理を任せ、要約だけをメイン会話へ戻す。

こうするとメインの長いコンテキストを動かさず、キャッシュ命中率を保ちやすい。

キャッシュを壊す要因2：途中でMCPを追加する、プラグインを再読み込みする

MCPはClaude Codeへツールを提供する。新しいMCPサーバーを追加するとツール一覧が変わる。ツール定義はコンテキスト鎖の最も左側にある。

Prompt Cacheの視点では、ツール一覧が変わると、その後ろのsystemとmessagesも再計算が必要になりやすい。MCPが多い場合、ツール定義そのものが多くのTokenを占めるため、失効コストは大きくなる。

ただし重要な細部がある。Claude Codeは通常、セッション起動時にMCP設定を読む。途中で設定を変えても現在のsessionにすぐ影響するとは限らない。本当に注意すべきなのは、再起動、resume、プラグイン再読み込み、ツール一覧の再構築が起きる場面だ。

おすすめは：

長いタスクの前に必要なMCPをまとめて用意する。
作業中に不足に気づいてインストールし、再読み込みする流れを避ける。
大きなMCPツールセットは必要時だけ使う、またはデフォルト有効数を減らす。
ほとんど使わないMCPを常時有効にしない。

ツール定義が安定していてこそ、Prompt Cacheは安定して命中する。

キャッシュを壊す要因3：途中でCLAUDE.mdを編集する

CLAUDE.mdはClaude Codeのプロジェクト記憶ファイルだ。ビルドコマンド、テストコマンド、設計上の約束、コードスタイル、プロジェクト固有の注意点を書くのに向いている。

便利だが、これもコンテキストに入る。Claudeのヘルプでは、CLAUDE.mdはセッション開始時に読まれ、ユーザーメッセージとしてClaudeへ渡されると説明されている。またAnthropicのPrompt Cacheも使われる。最初のリクエストでは通常の入力価格を払い、以後キャッシュが有効なら低いcache readコストで処理される。

問題は、CLAUDE.mdが内容で識別されることだ。ファイル内容を変えると、旧キャッシュとは一致しない。

そのため、長いタスクの途中で頻繁にCLAUDE.mdを編集しないほうがよい。より良い使い方は：

タスク開始前にCLAUDE.mdが十分か確認する。
安定したルールはファイルへ、臨時指示は現在の会話へ置く。
一度だけの要望のために長期記憶ファイルを編集しない。
どうしても変更するなら、次の段階を新しいsessionや新しいフェーズとして扱う。

CLAUDE.mdは安定したプロジェクト説明であり、毎回変えるメモ帳ではない。

キャッシュを壊す要因4：途中でSkillsをインストールまたは更新する

Skillsもコンテキストの一部だ。新しいSkillを入れる、Skillを更新する、Skill一覧が変わると、セッションへ注入されるコンテキストも変わる。

こうした変化は、reload、resume、新しいsessionで反映されることが多い。messagesが再構築されると、古いキャッシュは命中しにくくなる。

MCPと同じく、次のように扱うとよい。

タスク開始前に必要なSkillsを決める。
同じ種類のタスクではSkillセットを固定する。
長いタスクの途中でSkillsを追加しない。
新しいSkillを入れたら、新しい段階の始まりとして扱う。

コンテンツ作成、レビュー、デプロイ、翻訳など反復する作業では、よく使うSkillsを固定するとコンテキスト構造が安定する。

キャッシュを壊す要因5：TTLを超えてアイドルになる

Prompt Cacheは永久に保存されない。一般的なデフォルト有効期間は数分程度で、Claude Code関連の説明でも約5分のキャッシュウィンドウが言及されることがある。TTLを過ぎると、同じリクエストでもサーバー側でキャッシュが消えている可能性がある。

長いタスクで「さっきまで安かったのに、少し離席したらTokenが増えた」と感じる原因はこれだ。

Claude Codeの出力を読む、ファイルを確認する、テストを走らせる、次の手を考える。こうした作業だけで5分はすぐ過ぎる。

環境が対応しているなら、長いタスクの前に1時間のPrompt Cache TTLを有効化できる。

`1`	`export ENABLE_PROMPT_CACHING_1H=1`

Windows PowerShellでは：

`1`	`$env:ENABLE_PROMPT_CACHING_1H="1"`

1時間キャッシュの書き込みコストは、通常5分キャッシュより高くなる。短いタスクには向かないこともあるが、大規模コードベース、長い会話、複雑な多段階開発では、頻繁にキャッシュが切れるより安くなる場合がある。

Tokenを節約しやすいClaude Code長タスクの組み方

安定した流れはこうだ。

タスク開始前にモデルを決め、頻繁に切り替えない。
必要なMCPを有効にし、不要なMCPは切る。
CLAUDE.mdは短く、安定した、長期的に有効なルールに絞る。
今回必要なSkillsを事前に準備する。
複雑なタスクでは1時間TTLを検討する。
大きなタスクは段階に分けるが、各段階の内部ではコンテキスト構造を安定させる。
支線探索はsubagentや別sessionで行い、メイン会話を汚さない。

目的はすべてのキャッシュミスをなくすことではない。見落としやすく、コストの高い失効を避けることだ。

簡単な判断基準

次の一文で判断できる。

この操作はモデル、ツール定義、システムコンテキスト、またはセッション冒頭の固定メッセージを変えるか？

答えがはいなら、Prompt Cacheに影響する可能性が高い。コンテキスト鎖の左側に近いほど影響は大きい。

よくある操作はこう整理できる。

モデル切り替え：高リスク。モデルごとにキャッシュが分離される。
MCP追加またはプラグイン再読み込み：高リスク。ツール一覧が変わる。
CLAUDE.md編集：中高リスク。プロジェクト記憶が変わる。
Skillsインストール：中高リスク。注入コンテキストが変わる。
通常の会話継続：低リスク。主にmessagesを追加するだけ。
TTL超過のアイドル：高リスク。サーバー側キャッシュが期限切れになる。

まとめ

Claude CodeのPrompt Cache最適化で大事なのは、パラメータを暗記することではなく、sessionの前方コンテキストを安定させることだ。

モデルを気軽に切り替えない。MCPやSkillsを作業途中で増やさない。CLAUDE.mdを臨時メモとして頻繁に編集しない。複雑なタスクではTTL延長を検討する。これらを守るだけで、長いタスクのTokenコストと応答速度はかなり予測しやすくなる。

実用的な一言にすると、始める前に整え、始めた後はあまり動かさない。

参考資料

Anthropic Founder’s Playbook解説：Claudeはスタートアップチームをどう加速するのか

Mon, 18 May 2026 18:02:58 +0800

AnthropicはClaude公式ブログで、創業者向けのThe Founder’s Playbookを公開した。中心にある問いは明確だ。AI-native startupは、洞察からプロダクト、ローンチ、スケールへどうすればより速く進めるのか。

このplaybookは、Claudeの機能一覧を紹介するだけのものではない。創業プロセスをIdea、MVP、Launch、Scaleの4段階に分けている。強調されているのは、AIに創業者の判断を置き換えさせることではなく、市場調査、コピーの初稿、コードの足場作り、運用フロー、営業資料といった反復的な作業をまずClaudeに任せ、創業者が判断、センス、取捨選択、信頼構築により多くの時間を使えるようにすることだ。

このplaybookは何を語っているのか

AIスタートアップが直面する圧力は、ますます圧縮競争のようになっている。プロダクトサイクルは短くなり、競争相手は増え、ユーザーは速度と品質を同時に求める。かつては複数人のチームで分担していた仕事も、いまではAIが第一稿を作り、創業チームがレビュー、修正、推進する形にできる。

Anthropicの枠組みは明快だ。最初から会社全体を完全に「AI化」しようとしない。まずは時間がかかり、反復的で、創造密度の低いプロセスを1つ見つける。Claudeに初稿、スクリプト、調査結果、実行チェックリストを生成させる。創業者は目標を定義し、方向を調整し、品質を判断し、有効な結果を実際の業務につなげる。

第1段階：Idea

Idea段階の重点は、「かっこいいアイデア」を思いつくことではない。そのアイデアにさらに投資する価値があるかを検証することだ。

Claudeはこの段階で、市場マップの整理、ユーザーの痛みの要約、競合ポジショニングの比較、潜在的な切り口の提案、曖昧なアイデアの具体的な価値提案への圧縮を支援できる。

ただし、最も重要なのは依然として人間の判断だ。AIはより多くの可能性を素早く見せてくれるが、「この市場に本当に強い需要があるか」という責任を代わりに負うことはできない。創業者は実際のユーザーと話し、既存のワークフローを変える意思があるか、さらには支払う意思があるかを観察する必要がある。

第2段階：MVP

MVP段階は、Claude Codeが特に力を発揮しやすいところだ。

小さなチームにとって、最も不足しがちなのはアイデアではなく、アイデアを試せるプロダクトに変える速度である。Claude Codeは足場作り、スクリプト作成、コンポーネント補完、境界条件の確認、技術方針メモの作成に関わり、チームが検証可能なバージョンへより速く到達するのを助ける。

ここで重要なのは、AIに一度で完璧なプロダクトを書かせることではない。ゼロから最初のバージョンまでの摩擦を下げることだ。創業者とエンジニアは、アーキテクチャ、セキュリティ、データ処理、ユーザー体験を引き続きレビューする必要がある。しかし、大量の機械的な初稿作業に時間を費やす必要は少なくなる。

第3段階：Launch

Launch段階で問われるのは、ナラティブ、配信、フィードバック速度だ。

多くのスタートアップチームは、ローンチの複雑さを過小評価する。ウェブサイトのコピー、プロダクトデモ、メール、ソーシャル投稿、ユーザーインタビュー、営業トーク、投資家向けアップデート。どれも「なぜ今このプロダクトが必要なのか」を明確に伝えなければならない。

Claudeはここで高頻度の協力相手になれる。異なるポジショニング案を生成し、ユーザー層ごとに紹介文を書き換え、ユーザーの疑問をシミュレーションし、ローンチの流れを整理し、初期フィードバックを次のプロダクトと市場施策に変換する。

第4段階：Scale

Scale段階では、テーマが「作ること」から「再現可能に成長すること」へ移る。

会社に安定したユーザーと収益が生まれ始めると、創業チームは運用、営業、サポート、データ分析、社内連携に引っ張られる。Claude Coworkのようなエージェント的能力は、より完結したタスクに向いている。たとえば市場調査、キャンペーン設計、資金調達戦略の整理、成長指標の要約、運用プロセスを繰り返し実行できる手順に分解することなどだ。

ここでAI-native企業と従来型ソフトウェア企業の違いが見え始める。本当の変化は、従業員がAIツールを使うことだけではない。会社のプロセスが最初からAIとの協働を前提に設計されることだ。どのタスクは人間が基準を定義するのか、どのタスクはAIに先に実行させるのか、どの結果はレビュー必須なのか、どのワークフローは再利用可能なテンプレートにできるのかを決める必要がある。

Claude Code、Claude Cowork、Chatは何に向いているのか

公式ブログの説明を見ると、Anthropicは創業者にClaudeを3種類の利用場面に分けて考えてほしいようだ。

Claude Codeはよりエンジニアリング寄りだ。コードを書く、スクリプトを生成する、境界ケースを分析する、コンポーネント仕様や技術ドキュメントを作る、といった用途に向いている。アイデアを動くものへ進めるための問題を解決する。

Claude Coworkは、委任できる仕事代理に近い。市場調査、キャンペーン設計、資金調達戦略、運用分析のように、継続的な実行が必要なタスクに向いている。比較的まとまった業務をまず一巡進めるための存在だ。

Claude Chatは、創業者の判断の瞬間に向いている。go-to-market戦略を考える、プロダクトポジショニングをストレステストする、ロードマップの優先順位を比較する、重要なナラティブを磨く。実行マシンではなく、素早く何度も議論できる思考パートナーである。

スタートアップチームに本当に役立つ点

このplaybookの価値は、創業者に「AIは重要だ」と告げることではない。それはもはや新しい話ではない。

より有用なのは、AIの使い方を散発的なツール呼び出しから、会社作りの方法論へ進めている点だ。各段階には異なるボトルネックがあり、それぞれのボトルネックはAIが参加できる部分に分解できる。

Idea段階では、AIが探索空間を広げる。MVP段階では、実装サイクルを圧縮する。Launch段階では、表現と配信実験を加速する。Scale段階では、再現可能なプロセスを蓄積する。

この考え方は小さなチームにとって特に重要だ。小さなチームにはすべての職能をカバーする人手がない。しかしAIを使えば、まず「第一版の能力」を補い、限られた人間の力を判断と関係構築が最も必要な部分に投入できる。

注意すべき落とし穴

最初の落とし穴は、AIが生成した内容をそのまま結論として扱うことだ。市場調査、競合分析、ユーザーペルソナ、成長戦略は、すべて実データとユーザーフィードバックで検証しなければならない。

2つ目は、レビューコストを低く見積もることだ。AIは初稿のコストを大きく下げられるが、コード品質、法的リスク、ブランド表現、商業上の約束、セキュリティ問題には、なお人間が責任を持つ必要がある。

3つ目は、早すぎる自動化だ。まだ手作業でうまく回っていないプロセスを、すぐにagentへ自動実行させるべきではない。より安定した方法は、まずワークフローの小さな一部にAIを参加させ、出力品質を観察し、段階的に範囲を広げることだ。

まとめ

AnthropicのThe Founder’s Playbookが伝えるシグナルは明確だ。AI-native startupの強みは、単にAIでコードを書けることではない。会社の初日から、AIをプロダクト、エンジニアリング、マーケティング、営業、運用にまたがる協働レイヤーとして組み込むことにある。

創業者にとって最も現実的な出発点は、壮大なAIワークフローを構築することではない。最も時間を消費し、最も反復的で、進行を最も遅らせているタスクを1つ選び、Claudeに最初の版を作らせることだ。本当の競争力は、人間の創業者が方向、品質、信頼をどう管理するか、そしてチームがこの協働方式を日常業務に安定して組み込めるかにかかっている。

参考資料

The founder’s playbook for the age of AI

easy-vibe：Vibe Coding初心者のための学習マップ

Sat, 16 May 2026 22:44:43 +0800

easy-vibe は、Datawhaleが公開しているVibe Coding学習プロジェクトです。対象は、すでにAIコーディングツールを使いこなしている開発者ではありません。Vibe Codingに触れ始めたばかりの学生、プロダクトマネージャー、デザイナー、運用担当者、個人開発者、技術好きの一般ユーザーです。

このプロジェクトの価値は、また別のAIツール一覧を作っていることではありません。「AIでどうやってプロジェクトを作り始めるか」を、より理解しやすい学習パスに分解していることです。多くの初心者にとって本当に難しいのは、Claude Code、Cursor、MCP、Agentの存在を知らないことではありません。最初に何を学び、どう練習し、いつ高度なツールに進むべきかが分からないことです。

Vibe Coding初心者に最も足りないのは道筋

Vibe Codingはここ数年注目されていますが、初心者にとって親切とは言えません。

表面上は、要件を説明できればAIにコードを書かせられるように見えます。実際には、タスクが少し複雑になるだけで問題が出ます。要件が曖昧、モデルが違うファイルを編集する、プロジェクト構造が分からない、エラーを処理できない、依存関係が入らない、プロンプトがどんどん乱れる。最後には「コードをチャットボックスにコピーする」状態へ戻ってしまいます。

そのため、Vibe Coding入門は「プロンプトの書き方」だけでは足りません。少なくとも次のことを解決する必要があります。

アイデアを実行可能なタスクに分ける方法。
AIにプロジェクト構造を理解させる方法。
モデルが生成したコードを読む方法。
エラーを処理し、反復する方法。
ターミナルとローカル開発環境を使う方法。
Webチャットから実際のAIコーディングツールへ移行する方法。

easy-vibeの意味はここにあります。ツール、チュートリアル、用語の中で初心者を迷わせるのではなく、これらを1つの学習ルートとして整理しようとしています。

単発チュートリアルではなくロードマップ

プロジェクト説明を見ると、easy-vibeは基礎チュートリアル、インタラクティブ演習、可視化コンテンツ、RAG、ターミナルツール、AIコーディングツール、さらにClaude Code、MCP、Skills、Agent Teamsなどの発展トピックを扱っています。

この構成は初心者に向いています。AIコーディングは単一のスキルではなく、複数の能力の組み合わせだからです。

要件を説明する。
タスクを分ける。
プロジェクトを読む。
モデルにコードを編集させる。
実行し、検証する。
エラーに基づいて反復する。
よく使う流れをツールやスキルとして蓄積する。

特定のツールだけを学ぶと、そのツールの画面に縛られやすくなります。モデル、エディタ、CLIが変わると、また何をすればよいか分からなくなります。ロードマップの利点は、先に作業方法を身につけ、その後でツールを適切な場所に置けることです。

非プログラマーに特に役立つ

Vibe Codingの最大の魅力は、専門プログラマーでなくてもプロトタイプを作れることです。

プロダクトマネージャーは製品アイデアをインタラクティブなdemoにできます。デザイナーはインタラクションのロジックを検証できます。運用担当者は社内ツールを書けます。学生は授業プロジェクトを素早く作れます。起業家は初期段階で需要を検証できます。こうした人たちは、従来の意味でフルタイムエンジニアになる必要はないかもしれませんが、「AIに手伝わせてアイデアを形にする」方法を持つ必要があります。

これが、easy-vibeが中国語コミュニティに合っている理由でもあります。多くの中国語ユーザーは、AIがコードを書けることをすでに知っています。しかし、開発環境、プロンプト、プロジェクト構造、デバッグ方法、Agentツールの使い方を体系的に学べる入門資料はまだ不足しています。中国語で明確に説明され、演習と一緒に進められることには意味があります。

この種のユーザーにとって最も重要なのは、最初から複雑なフレームワークを学ぶことではありません。まず、要件を出す、プロジェクトを生成する、動かす、問題を見つける、修正を続ける、最終的に使えるものを得る、という一連のループを回すことです。

発展部分は実際のAI開発ワークフローに近づく

easy-vibeで触れられているClaude Code、MCP、Skills、Agent Teamsは、もはや単なる入門概念ではありません。

Claude Codeはターミナル型コーディングAgentを表します。モデルがローカルプロジェクトに入り、ファイルを読み、コードを変更し、コマンドを実行できます。MCPはツールとデータソースの接続を解決し、モデルをチャットボックス内に閉じ込めません。Skillsは、固定のプロジェクト生成、文書整理、テストチェック、コンテンツ制作などの再利用可能な流れを蓄積します。Agent Teamsはさらに、タスクを複数の智能体へ分割します。

これらは初心者には少し遠く感じるかもしれません。それでも早めに知っておく価値があります。Vibe Codingの方向性は明確だからです。「AIに一部のコードを書かせる」段階から、「AIに完全なプロジェクトフローへ参加させる」段階へ向かっています。

学習ルートがプロンプトだけで止まると、ツールの進化についていけません。一方で、最初からすべての高度な概念を初心者に投げると、どこから始めればよいか分からなくなります。easy-vibeの良さは、それらを段階的なアップグレードの道筋に置いていることです。

学習時に避けたい2つの誤解

1つ目は、Vibe Codingならコードが分からなくても完全にコードを気にしなくてよい、と思うことです。

AIは多くのものを生成できますが、ユーザーは結果が正しいか判断する必要があります。少なくとも、プロジェクト構造を理解し、どう実行するかを知り、エラーがどこで起きているかを大まかに把握する必要があります。複雑なコードを書かなくても、基本的なエンジニアリング常識は必要です。

2つ目は、高度なツールほど良いと思うことです。

初心者が最初からClaude Code、MCP、複数Agentを必要とするとは限りません。より良い順序は、まず簡単なプロジェクトでフィードバックループを作り、その後でターミナル、バージョン管理、テスト、ツール呼び出し、自動化フローを少しずつ導入することです。ツールはタスクの複雑さに合わせるべきです。そうでなければ「強そうだが何に使うか分からない」ものになります。

どう使うとよいか

Vibe Codingに触れ始めたばかりなら、easy-vibeを学習チェックリストとして使えます。

まず基礎概念と簡単な演習から始めます。すべてのツールを追う必要はありません。個人ホームページ、データダッシュボード、フォームツール、自動化スクリプト、知識ベースdemoなど、小さなプロジェクトを1つ作ります。その過程で、AIがどこで助けになるか、どこは自分で確認すべきかを観察します。

小さなプロジェクトを安定して完成できるようになったら、より複雑な内容に進みます。

ターミナルツールでローカルプロジェクトを扱う。
Gitで各変更を管理する。
RAGで自分の資料を接続する。
MCPで外部ツールを接続する。
Skillsで反復作業を固定化する。
Agent Teamsで複雑なタスクを分割する。

このように学ぶVibe Codingは、単にAIへ質問することではありません。AIを自分のワークフローに入れることです。

まとめ

easy-vibeは、Vibe Codingの中国語入門マップとして見るのがよいでしょう。散らばったAIコーディングの概念、ツール、演習を1つの道筋にまとめ、初心者が「AIはコードを書けるらしい」から「AIでプロジェクトを作れる」へ進みやすくしています。

Vibe Codingの本当の価値は、すべての学習を飛ばせることではありません。アイデアからプロトタイプまでのハードルを下げることです。要件を理解し、タスクを整理し、結果を検証し、リスクを制御する必要は残ります。ただし、多くの反復的で退屈で詰まりやすい手順は、AIに手伝わせることができます。

AIコーディングに体系的に入門したいが、最初からツール名や複雑な開発設定に埋もれたくないなら、easy-vibeは保存しておきたい出発点です。

Claude Code + Ollama ローカル導入ガイド：CC Switch で無料の AI コーディングアシスタントを作る

Fri, 15 May 2026 23:27:50 +0800

最近、Claude Code のような AI コーディングアシスタントが注目されています。魅力は単にコードについて会話できることではなく、プロジェクトを読み、ファイルを編集し、コマンドを実行し、依存関係を入れ、エラーを見ながら修正を続けられる点にあります。かなり Agent に近い使い方ができます。

ただし問題はコストです。プロジェクトが大きくなるとコンテキストも長くなり、複数ターンの Agent 操作で API クォータを一気に消費します。試用、小さなツールの修正、スクリプト作成、ローカルのプライベートプロジェクトで使いたいだけなら、Claude Code の操作感を残したままモデルだけローカルにできないか、と考えるのは自然です。

この構成の鍵になるのが CC Switch です。Claude Code から OpenAI 互換 API としてローカルの Ollama サービスへ接続し、公式 Claude API ではなくローカルモデルへリクエストを転送できます。

この構成で解決できること

全体の流れは次のように考えると分かりやすいです。

1
2
3

Claude Code デスクトップ
+ CC Switch API 転送レイヤー
+ Ollama ローカルモデル

Claude Code は引き続きコーディングワークフローとプロジェクト操作を担当します。CC Switch はモデルプロバイダー設定と API 互換性を受け持ち、Ollama はローカルでモデルを動かします。

これはローカルモデルが突然 Claude と同等になるという意味ではありません。価値があるのは、Claude Code の Agent ワークフローを低コスト、オフライン、プライベートなローカル環境で使えるようにする点です。

基本準備

始める前に、次のものを用意します。

Git をインストールする。
Ollama をインストールする。
コーディング向きのローカルモデルを取得する。
CC Switch をインストールする。
Claude Code をローカルで使える状態にする。

モデルは、まずコード能力が比較的強いものから試すとよいでしょう。たとえば Qwen Coder、DeepSeek Coder、またはツール呼び出しとコード生成がある程度安定しているモデルです。大きいモデルほど結果は良くなりやすい一方、メモリや GPU への負荷も高くなります。

メモリに余裕がないマシンでは、小さめのモデルで流れを確認してから、徐々に大きいモデルを試すのがおすすめです。

CC Switch の重要設定

Ollama を起動すると、通常のローカル API アドレスは次のようになります。

`1`	`http://127.0.0.1:11434/v1`

CC Switch では OpenAI 互換のプロバイダー種別を選びます。よく使う選択肢は次のものです。

`1`	`OpenAI Chat Completions`

そのうえで base URL を Ollama のローカルアドレスに向けます。

API key はローカル Ollama では通常、本物のキーを必要としません。ただし多くのツールは環境変数やプレースホルダーを求めます。次のような値を使えます。

`1`	`ANTHROPIC_API_KEY`

または、手元のローカル設定で受け入れられる別のプレースホルダー変数でも構いません。

特に注意したい設定項目があります。

`1`	`"inferenceModels"="[\"haiku\",\"sonnet\",\"opus\"]"`

これは Claude Code が期待するモデルロールをローカルプロバイダーへマッピングする設定です。実際には haiku、sonnet、opus を Ollama または CC Switch 側で利用できるモデル名に対応させる必要があります。この対応が間違っていると、Claude Code がモデルを呼べなかったり、意図しない設定へ戻ったりします。

Claude Code の強み

Claude Code の一番の価値は、単発の補完ではなくコーディング全体のワークフローにあります。

プロジェクト構造を読み取って理解する。
タスクに応じて関連ファイルを見つける。
コードを直接編集する。
コマンドやテストを実行する。
エラーを観察して修正を繰り返す。
1 つのセッションで複数ステップの作業を進める。

多くの人が Claude Code を残したい理由もここにあります。通常のチャット UI でもコード片は生成できますが、リポジトリ内で自然に作業してくれるわけではありません。Claude Code は、実行できる開発アシスタントに近い存在です。

Ollama の役割

Ollama はローカルモデルの実行と管理を担当します。モデルのダウンロード、ロード、ローカル推論を扱います。

利点は明確です。リクエストは手元のマシンに残り、繰り返し使っても API 課金が発生せず、ネットワークが制限された環境でも使えます。プライベートなコードを扱う場合も、すべてのコンテキストをクラウドモデルに送るより受け入れやすいでしょう。

一方で代償もあります。ローカルモデルはハードウェアとモデル品質に大きく左右されます。小さいモデルでも簡単な修正、説明、スクリプト生成はできますが、大規模な複数ファイルリファクタリングや細かな設計判断では能力差が出やすくなります。

体験の限界

この構成は、Claude の強力なクラウドモデルを完全に置き換えるものとして考えるべきではありません。

次のような問題に遭遇する可能性があります。

長いコンテキストの理解が弱い。
複雑なタスクでツール呼び出しが不安定になる。
CPU のみの環境では推論が遅い。
存在しないファイルパスや API を幻覚しやすい。
複数ターンの計画が安定しにくい。
大規模リポジトリのリファクタリング成功率が低い。

したがって、期待値としては「無料で使えるローカル開発アシスタント」が現実的です。トップクラスのクラウドモデルの完全な代替ではありません。

マルチモーダル互換性はまだ不安定

Claude Code にスクリーンショット、UI 画像、図、その他のマルチモーダル入力を扱わせたい人もいます。この部分はローカルモデルと転送レイヤーの対応状況に依存します。

選んだ Ollama モデルが画像入力に対応していない場合、または CC Switch がリクエスト形式を正しく変換できない場合、マルチモーダル機能は失敗する可能性があります。Vision モデルを使っても、公式 Claude API と同じ挙動になるとは限りません。

現時点では、この構成はテキストとコードのワークフロー向きです。マルチモーダル対応は実験的なものとして扱うのがよいでしょう。

試す価値がある人

この構成は次のような人に向いています。

Claude Code のワークフローを低コストで試したい開発者。
スクリプト、小さなツール、自動化をよく書く人。
コードをできるだけローカルに残したいチーム。
API コストを気にせず AI コーディングアシスタントを学びたい初心者。
さまざまなローカルコードモデルを検証している人。

長いコンテキスト、大規模 monorepo、厳密なコードレビュー品質、複雑なプロジェクト全体のリファクタリングに強く依存する場合は、まだ安定性が足りないかもしれません。

使い方のおすすめ

まずは小さなタスクから始めましょう。

たとえば次のような作業です。

1 つのファイルを説明させる。
小さな関数をリファクタリングする。
shell スクリプトを生成する。
単純なエラーを修正する。
小さな機能を追加する。
狭いモジュールに単体テストを追加する。

変更後は、自分でテストを実行するか、少なくとも diff を確認してください。ローカルモデルは便利ですが、生成された編集をすべて無条件に受け入れるべきではありません。

モデルがよくコンテキストを見失う場合は、タスク範囲を小さくします。「プロジェクト全体をリファクタリングして」ではなく、「この関数をリファクタリングして」や「このファイルにバリデーションを追加して」のように依頼すると安定しやすくなります。

まとめ

Claude Code + CC Switch + Ollama はかなり面白い組み合わせです。Claude Code の Agent 的な開発体験を保ちつつ、モデル推論をローカルへ移せます。

大きな利点は、コストの低さ、データのプライバシー、扱いやすい開発ワークフローです。一方で、モデル品質、ハードウェア性能、長いコンテキスト、ツール呼び出しの安定性が体験を左右します。

すでに Ollama を使っていて、より実践的なローカル AI コーディング環境が欲しいなら、この構成は試す価値があります。ただし小さな作業から始め、すべての変更を確認し、ローカルモデルを自動エンジニアではなくアシスタントとして扱うのが安全です。

Superpowers：Coding Agent を工学プロセスへ戻す skills フレームワーク

Fri, 15 May 2026 08:53:17 +0800

obra/superpowers は coding agent 向けの skills フレームワークであり、ソフトウェア開発方法論でもある。目的は万能 prompt を増やすことではなく、agent に流れを守らせることだ。目標を確認し、設計を作り、計画に分解し、TDD で実装し、レビューして終える。

プロジェクト：https://github.com/obra/superpowers

執筆時点で GitHub API では 19 万 star を超え、MIT ライセンスで、最近も更新されている。README は An agentic skills framework & software development methodology that works. と説明している。

解決したい問題

多くの AI コーディングツールの問題は、コードを書けないことではなく、すぐコードを書き始めることだ。

ユーザーが曖昧な要望を言うと、agent はファイルを編集し、見た目は完成する。しかし境界、テスト、アーキテクチャは不明確なまま残る。小さな作業ならよいが、複雑なプロジェクトでは手戻りと技術的負債になる。

Superpowers は、コードに触る前に agent を workflow に入れる。

何かを作りたいと分かったら、まず目標を質問する。
会話を仕様にし、区切って確認する。
設計が通ったら、実装計画を作る。
ユーザーが “go” と言ってから実装する。
実装では TDD、YAGNI、DRY、レビューを重視する。

これは新しい工学ではない。速い agent ほど、こうしたガードレールが重要になる。

対応ツール

Superpowers は単一の agent に縛られない。README には Claude Code、Codex CLI、Codex App、Factory Droid、Gemini CLI、OpenCode、Cursor、GitHub Copilot CLI が挙げられている。

つまり特定モデルのテクニックではなく、複数の harness で使える workflow 層に近い。

基本 workflow

最初は brainstorming。実装前に粗いアイデアを実行可能な設計へ変え、ユーザーに確認する。

次に using-git-worktrees。設計後、隔離された worktree とブランチを作り、インストールとテストの基線を確認する。

次は writing-plans。設計を小さなタスクに分け、ファイルパス、変更範囲、検証手順を明確にする。

実装段階では subagent-driven-development で subagent に渡すことも、executing-plans で順に実行することもできる。重要なのは各タスクが確認可能で review 可能なことだ。

その後 test-driven-development によって、本当の RED-GREEN-REFACTOR を行う。失敗するテストを書き、失敗を確認し、最小実装で通し、リファクタリングする。

さらに requesting-code-review でタスク間の review を行う。Critical な問題は進行を止める。

最後に finishing-a-development-branch でテストを確認し、merge、PR、worktree の保持や破棄を選ぶ。

Skills Library

テスト系は test-driven-development が中心だ。

デバッグ系には systematic-debugging と verification-before-completion がある。再現、最小化、仮説、検証、修正を求め、検証なしに完了と言わない。

協調系には次がある。

brainstorming
writing-plans
executing-plans
dispatching-parallel-agents
requesting-code-review
receiving-code-review
using-git-worktrees
finishing-a-development-branch
subagent-driven-development

メタ skills には writing-skills と using-superpowers がある。組み合わせると、agent に「いつ質問し、いつ計画し、いつテストし、いつ止まって review するか」という習慣を与える。

普通の prompt との違い

普通の prompt は、ルールを system prompt に積み上げがちだ。勝手に変更するな、先に考えろ、テストしろ、簡潔に説明しろ。ルールが増えるほど、複雑なタスクでは忘れられやすい。

Superpowers はルールを段階ごとの workflow モジュールに分ける。各 skill は短く、目的が集中している。agent は今の段階で何をすべきかを理解しやすく、複雑な流れも検査しやすい。

学べる点は、賢いモデルだけを追うのではなく、モデルに繰り返し可能な働き方を与えることだ。

向いている場面

Superpowers は、実プロジェクトで coding agent を使う開発者に向いている。複数ファイルの変更、設計してから実装したい場合、TDD や検証が必要な場合、複数ブランチや worktree を扱う場合、subagent に実装や review を任せたい場合に特に有効だ。

一行の設定変更には重いかもしれない。しかし多段階の開発では、その制約が価値になる。

注意点

これは自動操縦ではない。プロセスは与えるが、要求、トレードオフ、最終受け入れは人間が持つ。

TDD と review は初期コストを増やす。小タスクでは遅く感じるが、複雑なタスクでは手戻りを減らす。

subagent の並列化は常に良いわけではない。境界と書き込み範囲が明確なときに効く。要件が曖昧なら、並列化は混乱を増やす。

まとめ

Superpowers の価値は、coding agent を「依頼を受けたらコードを書く」状態から、ソフトウェア工学プロセスへ戻すことにある。

AI コーディングに足りないのは生成速度ではなく、確認、計画、検証、review、終了処理であることが多い。モデルが強くなるほど、これらを省いてはいけない。

Codex、Claude Code、Cursor、Gemini CLI を実プロジェクトで使っているなら、Superpowers は調べる価値がある。直接使わなくても、skills の分け方は自分の agent workflow を設計する参考になる。

Vibe Coding を拒む：Matt Pocock の skills リポジトリが AI コーディングに工学的制約を足す

Fri, 15 May 2026 08:46:23 +0800

AI がコードを書く速度が上がるほど、プロジェクトが崩れる速度も上がり得る。問題はモデルが関数を生成できるかではなく、要件を理解し、チームの言葉に従い、既存アーキテクチャの中で小さく進められるかだ。

Matt Pocock が公開した mattpocock/skills は、vibe coding とは逆の方向を示している。AI に開発プロセス全体を任せるのではなく、成熟したソフトウェア工学の制約の中に置く。

プロジェクト：https://github.com/mattpocock/skills

これは魔法の prompt ではない。要件確認、ドメインモデリング、TDD、診断、アーキテクチャレビューを、AI agent が使いやすい workflow にした skills の集合だ。

まずアラインメント失敗を防ぐ

AI コーディングで最も多い失敗は、モデルが理解したと思ったら、実は曖昧な説明から推測していただけ、というものだ。

grill-me はこれを反転させる。コードを書く前に、AI を厳しいレビュアーにし、分岐、境界、未決事項を質問させる。

たとえば「ログインページを作って」と頼んだら、先に聞くべきことは次のようなものだ。

パスワード忘れはどう扱うか
外部ログインをサポートするか
ログイン失敗時のエラー表示はどうするか
アカウントロック、CAPTCHA、リスク制御は範囲内か
成功後はどこへ遷移するか

この段階は遅く見えるが、後の手戻りを減らす。コード生成が安くなるほど、曖昧な要件のコストは大きくなる。

ドメイン言語をコンテキストに入れる

次の問題は汎用語彙だ。モデルはチーム内の業務用語を知らないため、変数名、関数名、ドキュメントの言葉がずれていく。

grill-with-docs は質問しながら、CONTEXT.md、ADR、ドメイン文書を確認する。確認済みの用語、境界、判断は、再利用できるコンテキストとして残せる。

これはドメイン駆動設計のユビキタス言語に近い。チームが user ではなく customer、order ではなく transaction と呼ぶなら、AI もその言葉を使うべきだ。

コンテキスト文書の価値は、情報量ではなく推測を減らすことにある。

TDD で生成速度を制御する

AI の危険は速さにある。昔は悪いコードを大量に書くにも時間がかかったが、今は数秒で数百行が出る。問題は速さそのものではなく、フィードバックループがないことだ。

tdd skill は RED-GREEN-REFACTOR を戻す。

ひとつの振る舞いに対して失敗するテストを書く。
そのテストを通す最小実装を書く。
リファクタリングする。
次の縦スライスへ進む。

重要なのは、ひとつずつ進めることだ。AI は実行し、人間は方向と境界を確認する。

診断ループで複雑な問題を扱う

バグに出会うと、多くの agent は答えを推測し、何度も修正して問題をさらに複雑にする。

diagnose は先にフィードバックループを作らせる。

再現する
最小化する
仮説を立てる
観測やログを足す
修正する
回帰テストを足す

古い方法だが、AI コーディングでは特に重要だ。AI は試行が得意だが、根因に近づいているかを判断するにはレールが必要になる。

アーキテクチャを定期的に見る

単発のタスクが通っても、コードベースが良くなったとは限らない。AI の小さな変更が積み重なると、モジュール境界がぼやけ、インターフェイスが複雑になり、テストしづらくなる。

improve-codebase-architecture のような skill は、現在のタスクから離れて全体を見る。

責務が混ざっているモジュールはどこか
複雑すぎるインターフェイスはどれか
テストしづらい経路はどこか
ドメイン言語と合わない命名はどれか
収束すべき重複ロジックはどれか

これは自動で大規模リファクタリングするためではない。構造化された観察と改善方向を出し、人間が判断するためのものだ。

制限すべきは自由度

この方法論の核心は単純だ。AI コーディングはモデルを自由に走らせることではなく、明確な目標、コンテキスト、テスト、停止条件を与えることだ。

人間は問題定義、アーキテクチャ境界、業務上の取捨選択、受け入れ基準を担当する。AI はコード生成、テスト補完、反復修正、局所的なリファクタリングを担当する。

AI が強くなっても、ソフトウェア工学の基礎は古くならない。要件整理、ドメイン言語、TDD、診断、アーキテクチャレビューは、むしろ重要になる。

コードを書ける人は増える。差がつくのは、AI を保守可能で検証可能な工学体系に組み込めるかどうかだ。

cc-haha とは？Claude Code をデスクトップ作業台にするプロジェクト

Thu, 14 May 2026 22:38:04 +0800

cc-haha は、Claude Code のワークフローを中心に改造されたプロジェクトです。正式なリポジトリ名は NanmiCoder/cc-haha です。プロジェクトページでは、2026-03-31 に Anthropic npm registry から流出した Claude Code のソースコードを修復したものをベースにしており、現在の主な形はデスクトップ版 Claude Code ワークベンチだと説明されています。

プロジェクト URL：https://github.com/NanmiCoder/cc-haha

この説明には重要な点が 2 つあります。

1 つ目は、これは Anthropic 公式の Claude Code ではないということです。README でも、元のソースコードの著作権は Anthropic にあり、学習と研究目的に限ると明記されています。

2 つ目は、今の重点が単なる「Claude Code CLI をローカルで動かすこと」ではないということです。README と最新 release を見ると、cc-haha は Claude Code のセッション、プロジェクト、権限、Diff、Computer Use、リモートアクセス、モデルプロバイダー設定をまとめるデスクトップアプリに近いものになっています。

何を解決しようとしているのか

Claude Code はもともとターミナル寄りのツールです。セッション、コマンド実行、権限確認、ファイル編集、コンテキスト切り替えはターミナル内で行われます。CLI に慣れた人には問題ありませんが、長く使うといくつか不便な点が出てきます。

複数のプロジェクトやセッションを同時に管理しづらい。
AI がどのファイルを変更したかを見るには、Git やエディタに切り替える必要がある。
権限承認、コマンド実行、ファイル Diff が別々の画面に分散する。
スマホや別端末から現在のセッションを見たい場合、追加の仕組みが必要。
Anthropic 以外のモデルを使うには、プロトコル互換を自分で処理する必要がある。

cc-haha は、これらをグラフィカルなワークベンチとしてまとめようとしています。Claude Code に見た目を付けただけではなく、「セッション管理」と「ローカル開発フローの制御」をデスクトップ側に移しています。

デスクトップワークベンチ：ターミナルからコントロールセンターへ

README によると、cc-haha のデスクトップ版は macOS / Windows App の中に次の機能を集約しています。

複数セッションのワークベンチ：タブ、プロジェクト切り替え、ターミナル入口、セッション履歴でタスクを管理。
ブランチ / Worktree 起動：新しいセッションでリポジトリブランチを選び、現在の作業ツリーか隔離 Worktree かを選択。
右側のコード変更パネル：チャットしながら変更済みファイル、追加削除行、ワークスペース状態を確認。
コード変更の可視化：AI による編集、Diff、実行過程を表示。
権限と確認フロー：危険なコマンド、ツール呼び出し、AI の確認質問をデスクトップで承認。
複数モデルプロバイダー：Anthropic 互換 API、第三者モデル、WebSearch fallback、ローカル設定をサポート。
H5 リモートアクセス：一度きりの token でスマホや別端末から現在のデスクトップセッションへ接続。
IM 連携：Telegram、Feishu、WeChat、DingTalk からリモート対話、プロジェクト切り替え、権限承認。
スケジュールタスクと token 使用量：デスクトップで計画タスクを作成し、ローカル token 使用傾向を確認。

これらの機能を見ると、単なるコマンドライン代替ではなく「AI コーディングワークベンチ」に近いことがわかります。チャット、ファイル変更、権限、プロジェクト、リモート入口、モデル設定を同じ場所に置こうとしているわけです。

インストールと起動方法

一般ユーザーは Releases からデスクトップ版インストーラーをダウンロードするのが向いています。

README のデスクトップ版インストール手順は次の通りです。

GitHub Releases から macOS または Windows のインストーラーをダウンロードする。
初回起動後、デスクトップ設定でモデルプロバイダー、API Key、デフォルトモデルを設定する。
macOS でアプリを開けないと表示された場合は、インストールガイドに従って Gatekeeper 権限を処理する。

最新 release ページでは、v0.2.6 が 2026-05-13 に公開されています。このバージョンは主に H5 モバイルアクセスの安全な復旧、デスクトップセッション管理、ファイル mention 検索、デスクトップ体験の細部改善を扱っています。

ソースから CLI を起動したい場合、README には次のコマンドが示されています。

1
2
3

bun install
cp .env.example .env
./bin/claude-haha

この方法は、低レベル CLI、サーバー、自前の開発を調べたい人向けです。普通に使うならデスクトップ版のほうが直接的です。

v0.2.6 の変更点

v0.2.6 の重点は、H5/LAN アクセスを一時的な開放状態から、明示的な有効化と token ペアリングモデルへ戻したことです。

注目点は次の通りです。

H5/LAN アクセスはローカルで明示的に有効化する必要がある。
QR リンクには一度だけ表示される token が含まれる。
リモート API、proxy、WebSocket は裸で公開されなくなった。
Settings に独立した H5 Access ページが追加された。
デスクトップのサイドバーに複数選択とセッション削除のための一括管理モードが追加された。
デスクトップのファイル mention 検索が git-first になり、ignore ルールを守り、node_modules やビルド成果物のノイズを減らす。
ピュアホワイトテーマが追加され、長い URL がチャットレイアウトを壊す問題や、複数 tab 間で下書きが混ざる問題が修正された。

これは、プロジェクトが「動く」段階を越えて、デスクトップ製品として必要な安全境界と日常的な使い勝手を補い始めていることを示しています。

特に H5 アクセスについて、作者は release で明確に注意しています。H5 は個人または信頼できるチーム向けのブラウザアクセス入口であり、公開マルチテナントログインシステムではありません。実際に使うときは、インターネットに公開する SaaS 管理画面のように扱うべきではありません。

Computer Use：Agent にデスクトップを操作させる

cc-haha のもう一つの大きな特徴は Computer Use です。

プロジェクト文書によると、この機能は流出した Claude Code ソース内の Computer Use 内部実装を大きく改造したものです。公式実装は @ant/computer-use-swift や @ant/computer-use-input といった Anthropic 内部の非公開ネイティブモジュールに依存しており、公開入手できません。cc-haha は低レベル操作層を Python bridge に置き換え、pyautogui、mss、pyobjc などの公開ライブラリでシステム操作を実現しています。

Computer Use が対応する操作には次のようなものがあります。

スクリーンショット：screenshot、zoom
マウス：クリック、ドラッグ、移動、スクロール、カーソル位置取得
キーボード：文字入力、キー入力、キー長押し
アプリ：アプリ起動、ディスプレイ切り替え
権限：アプリ権限要求、許可済みアプリ一覧
クリップボード：読み取りと書き込み
その他：待機、バッチ操作

動作は「スクリーンショット - 分析 - 操作」のループです。

モデルがユーザーの依頼を受け取る。
screenshot を呼び出して画面を取得する。
モデルが視覚能力でボタン、入力欄、座標を識別する。
クリック、入力、アプリ操作ツールを呼び出す。
再度スクリーンショットを取り、結果を確認して次へ進む。

文書を見る限り、完全対応している主なプラットフォームは macOS で、Apple Silicon と Intel の両方を含みます。Windows / Linux は理論上可能ですが、pyobjc に関わるアプリ管理部分を各プラットフォーム向けに置き換える必要があり、現時点では完全対応ではありません。

実行要件は次の通りです。

Bun >= 1.1.0
Python >= 3.8
macOS Accessibility 権限
macOS Screen Recording 権限

この種の機能は強力ですが、権限リスクも高くなります。AI にデスクトップアプリを操作させる場合、必要なアプリだけを明示的に許可し、関係ないウィンドウに機密情報を開いたままにしないほうがよいです。

複数モデル接続：Anthropic 互換レイヤーを使う

cc-haha の通信基盤は引き続き Anthropic Messages API プロトコルです。プロジェクト文書では、LiteLLM をプロトコル変換プロキシとして使う方法が推奨されています。

基本構造は次の通りです。

`1`	`claude-code-haha ──Anthropic协议──▶ LiteLLM Proxy ──OpenAI协议──▶ 目标模型 API`

つまり、cc-haha は Anthropic Messages API リクエストを送り、LiteLLM がそれを OpenAI Chat Completions などの形式へ変換し、OpenAI、DeepSeek、Ollama、その他のモデルサービスへ転送します。

文書にある LiteLLM のインストール方法は次の通りです。

`1`	`pip install 'litellm[proxy]'`

その後、litellm_config.yaml で OpenAI、DeepSeek、Ollama などのモデルを設定できます。プロキシ起動後、.env または ~/.claude/settings.json に次を設定します。

ANTHROPIC_AUTH_TOKEN=sk-anything
ANTHROPIC_BASE_URL=http://localhost:4000
ANTHROPIC_MODEL=gpt-4o
ANTHROPIC_DEFAULT_SONNET_MODEL=gpt-4o
ANTHROPIC_DEFAULT_HAIKU_MODEL=gpt-4o
ANTHROPIC_DEFAULT_OPUS_MODEL=gpt-4o
API_TIMEOUT_MS=3000000
DISABLE_TELEMETRY=1
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1

実用上の注意点もあります。

drop_params: true が重要です。Anthropic の thinking や cache_control などのパラメータは OpenAI API には存在しないためです。
Extended Thinking は Anthropic 固有機能なので、第三者モデルでは使えません。
Prompt Caching も Anthropic ネイティブの形では機能しません。
ツール呼び出しは Anthropic tool_use から OpenAI function calling へ変換されるため、複雑なツール呼び出しでは互換性問題が出る可能性があります。
ローカル Ollama の小さなモデルでは、このツール呼び出し中心の流れを安定して処理できない場合があります。

したがって、複数モデル接続は可能ですが、すべてのモデルで同じ体験になるわけではありません。cc-haha はモデルに対して、ツール呼び出し、コード理解、長いコンテキスト処理の能力をかなり要求します。

向いている人

cc-haha は次のようなユーザーに向いています。

Claude Code に慣れていて、デスクトップでセッション管理したい人。
複数のリポジトリ、ブランチ、AI セッションを同時に扱う人。
AI のファイル変更、Diff、ワークスペース状態を右側で直接見たい人。
Computer Use を試し、Agent にデスクトップアプリを操作させたい人。
Anthropic プロトコル経由で OpenAI、DeepSeek、Ollama などを接続したい人。
スマホや IM からリモートでセッション確認や権限承認をしたい人。

あまり向いていないのは次のような場合です。

安定した公式 Claude Code だけを使いたい。
流出ソースという背景や著作権の不確実性を受け入れられない。
ローカルツールに高いシステム権限を与えたくない。
企業のコンプライアンス、監査、公式サポートが必要。
API key、プロキシ、モデル互換、ローカルサービス設定に慣れていない。

リスクと境界

この話では機能だけでなく、リスクも扱う必要があります。

cc-haha の由来を考えると、これは普通のコミュニティ再実装プロジェクトではありません。README には、流出した Claude Code ソースコードをベースにしており、元のソースコードは Anthropic に帰属すると明記されています。これは著作権、コンプライアンス、長期保守の不確実性につながります。

また、Computer Use、H5 リモートアクセス、IM 連携、ローカル権限承認はいずれも高い権限を持つ機能です。便利であるほど、境界を明確にする必要があります。

信頼できないネットワークで H5 アクセスを開放しない。
token を長期公開ログイン資格情報として扱わない。
Agent に無関係な機密アプリを操作させない。
本番環境や企業コンプライアンス環境で安易に使わない。
第三者モデルプロキシ設定や API key を公開リポジトリに置かない。

AI コーディングツールの構造、デスクトップワークフロー、Computer Use 実装を学ぶ目的なら、とても参考になります。長期の本番ワークフローに入れるなら、先に法務、権限、セキュリティ、保守のリスクを評価すべきです。

まとめ

cc-haha で最も注目すべき点は、「Claude Code を再現できるか」ではありません。Claude Code 型の AI コーディングツールを、デスクトップワークベンチの形へ押し出していることです。

セッション、プロジェクト、Worktree、Diff、権限、リモートアクセス、Computer Use、複数モデルプロバイダー、スケジュールタスク、token 使用量統計が、1 つのデスクトップ体験にまとめられています。これは、AI コーディングツールの次の一歩が、モデル性能だけでなく、より完成度の高いワークフロー UI にもあることを示しています。

ただし境界も明確です。これは Anthropic 公式製品ではなく、出自に敏感な背景があり、高権限機能は慎重に扱う必要があります。公式 Claude Code を安易に置き換えるものとしてではなく、AI コーディングツールの進化方向を観察するプロジェクトとして見るのが適切です。

参考資料

GitHub リポジトリ：https://github.com/NanmiCoder/cc-haha
最新 Release：https://github.com/NanmiCoder/cc-haha/releases/tag/v0.2.6
Computer Use ドキュメント：https://github.com/NanmiCoder/cc-haha/blob/main/docs/computer-use.md
第三者モデルドキュメント：https://github.com/NanmiCoder/cc-haha/blob/main/docs/guide/third-party-models.md

Codex /goal vs Claude Code /goal：長いタスクを完了条件まで自動で進める

Thu, 14 May 2026 22:25:31 +0800

/goal は、AI コーディングツールにおける重要なコマンドになりつつあります。

これは「モデルにもう少しコードを書かせる」ためのものではありません。より実用的な問題、つまりタスクに明確な完了条件があるとき、毎ターン止まってユーザーの「続けて」を待つのではなく、Agent が条件を満たすまで進み続けられるか、という問題を扱います。

Codex CLI はすでに公式ドキュメントで実験的な /goal を追加しています。Claude Code も独自の /goal ドキュメントを公開し、複数ターンにまたがって作業を続けられる自動化機能として説明しています。名前は同じですが、プロダクトとしての方向性は完全には同じではありません。

`/goal` は何を解決するのか

通常の AI コーディング対話は、だいたい「一問一答」です。

ユーザーがタスクを出す。
Agent が分析し、コードを変更し、テストを実行する。
Agent が結果を報告する。
ユーザーが次の行動を決める。

この流れは短いタスクには向いています。しかし移行、リファクタリング、テスト修正、issue backlog の整理になると、かなり細切れになります。Agent は少しだけ進めて、また「続けて」と入力されるのを待つことがあります。

/goal の考え方は、タスクを「次に何をするか」ではなく「最終的にどんな状態なら完了か」に変えることです。たとえば：

`1`	`/goal 完成登录模块迁移，所有 auth 测试通过，lint 无报错`

この種の目標は長いタスクに向いています。テストが通る、ビルドが成功する、ファイル分割が終わる、キューが空になる、受け入れ条件を満たす、といった明確な終点があるからです。

Codex の `/goal`：実験機能で、現在のスレッドに紐づく

OpenAI の Codex CLI ドキュメントでは、/goal は実験機能として扱われています。デフォルトの安定機能ではなく、先に features.goals を有効にする必要があります。

有効化する方法は 2 つあります。

`1`	`/experimental`

または config.toml に追加します。

1
2

[features]
goals = true

有効化後は、次のように使えます。

`1`	`/goal Finish the migration and keep tests green`

よく使うコマンドは次の通りです。

/goal
/goal pause
/goal resume
/goal clear

OpenAI のドキュメントによると、Codex は goal を現在の active thread に付与し、より大きなタスクの進行中にその目標を追跡します。

ここで重要なのは、Codex /goal に対する公式ドキュメントの表現がかなり抑制的であることです。「長いタスクに実験的な目標を設定する」「現在のスレッドに目標を付与する」と説明していますが、Claude Code のドキュメントのように、各ターンの終了後に独立した evaluator が自動判定して次のターンへ進む、という説明まではしていません。そのため現時点では、Codex /goal は完全に安定した無人実行モードではなく、実験中の長期タスク向け目標メカニズムとして見るのがよさそうです。

Claude Code の `/goal`：完了条件で駆動する複数ターン実行

Claude Code の /goal ドキュメントはより明確です。ユーザーが completion condition を設定すると、Claude はその条件が満たされるまで複数ターンにわたって作業を続けます。

例：

`1`	`/goal all tests in test/auth pass and the lint step is clean`

Claude Code の仕組みは、おおまかに次のようなものです。

現在の turn が終わっても、すぐに制御をユーザーへ戻さない。
小さく高速なモデルが、目標条件がすでに満たされたかを確認する。
満たされていなければ、Claude が自動で次のターンを開始する。
満たされていれば、goal は自動で解除され、transcript に完了状態が記録される。

つまり Claude Code の /goal は、「完了条件を満たすまで自動で続ける」機能に近いものです。単に会話へ目標を貼り付けるだけではなく、「次のターンへ進むかどうか」を独立した評価ステップに任せています。

Claude Code では、状態を直接確認することもできます。

/goal

状態には、目標条件、実行時間、評価済み turn 数、token 消費量、evaluator が最後に出した理由が表示されます。

途中で止めたい場合は、次を使います。

`1`	`/goal clear`

stop、off、reset、none、cancel も解除用の別名として使えます。目標を有効にした後でセッションが中断された場合でも、--resume や --continue で再開すると、active な goal を復元できます。ただし、経過時間、turn 数、token の基準値は再計算されます。

最大の違い

Codex と Claude Code はどちらも、AI コーディングを「単発の回答」から「長いタスクの実行」へ押し出しています。ただし /goal の位置づけには違いがあります。

比較項目	Codex CLI `/goal`	Claude Code `/goal`
状態	experimental	公式ドキュメントで単独ページとして説明
有効化	`features.goals` を有効化する必要がある	信頼済み workspace で直接利用可能
目標のスコープ	現在の active thread	現在の session
主な操作	set / view / pause / resume / clear	set / view / clear
自動判定	ドキュメントは目標の付与と追跡を強調	各ターン後に evaluator が判定すると明記
自動継続	公式表現は控えめ	条件未達なら自動で次のターンへ進む
向いている場面	Codex の長いタスクで目標コンテキストを維持したい場合	完了条件に向けて Claude Code に継続実行させたい場合

簡単に言えば、Codex の /goal は「現在のスレッドに実験的な長期目標を付ける」ものに近いです。Claude Code の /goal は「現在のセッションに検証可能な停止条件を設定し、満たされるまで自動で進める」ものに近いです。

よい `/goal` の書き方

どちらのツールでも、/goal は曖昧な願望を書く場所ではありません。

あまりよくない例：

`1`	`/goal 把项目优化一下`

よりよい例：

`1`	`/goal 将 payment 模块迁移到新 API，npm test -- payment 退出码为 0，git diff 只包含 payment 相关文件`

よい目標には通常、次の 3 つが含まれます。

明確な完了状態。
実行可能な検証方法。
守るべき境界。

目標が大きい場合は、停止条件も加えるべきです。

`1`	`/goal 修复 eslint 报错，npm run lint 退出码为 0；如果超过 20 轮仍未完成，停止并总结剩余问题`

これは重要です。/goal が強力になるほど、境界が必要になります。そうしないと Agent は「完了」を追い求めて、過剰にファイルを変更したり、長く走りすぎたり、token を使いすぎたり、本来なら質問すべき問題をそのまま進めてしまう可能性があります。

`/goal` が向いている場面

向いているもの：

テスト修正：指定したテストが通るまで。
コード移行：すべての呼び出し箇所を変更し、コンパイルが成功するまで。
一括整理：特定の lint や型エラーがゼロになるまで。
ドキュメント補完：指定したすべてのモジュールに説明が付くまで。
issue キュー処理：特定タグの issue が処理済み、または明確に分類されるまで。

向いていないもの：

要件自体がまだ曖昧。
頻繁なプロダクト判断が必要。
高リスクな削除、データ移行、権限変更を含む。
受け入れ条件が主観でしか判断できない。
大量の無関係なモジュールをまたぐ。

実用的な基準は、「どのコマンドを実行し、どんな結果を確認し、どのファイルに触れてはいけないか」を書けるなら /goal に向いている、ということです。「もっとよくして」としか書けないなら、通常の対話、計画モード、人間のレビューを使うほうが安全です。

AI コーディングツールへの影響

/goal は明確な方向性を示しています。AI コーディングツールは「対話型アシスタント」から「継続実行できる作業単位」へ移りつつあります。

以前は、Agent にタスクを任せるとき、ユーザーが近くで見守る必要がありました。詰まったら促し、テストが終わったら続行させ、エラーが出たらまた命令する。/goal はこのやり取りを完了条件に圧縮し、次のターンで何をするかを Agent 自身に決めさせます。

ただし、これはユーザー側への要求も高めます。これからの prompt はタスクを説明するだけでなく、受け入れ条件、検証コマンド、変更範囲、停止ルールも書く必要があります。言い換えると、ユーザーの仕事は「続けてと促す」ことから「何をもって完了とするかを定義する」ことへ移ります。

Codex と Claude Code が /goal に到達したということは、長いタスクを扱う Agent が、もはやバックグラウンドタスクやクラウドキューだけのものではないということです。ターミナル上のローカルなコーディングツールにも、より強い自律的な進行能力が求められ始めています。

まとめ

Codex CLI と Claude Code はどちらも /goal を持っていますが、現時点では同じ機能として単純に扱わないほうがよいです。

Codex の /goal はまだ実験機能で、features.goals を有効にする必要があり、現在の Codex スレッドで長期目標を維持する仕組みとして見るのが自然です。Claude Code の /goal は、「完了条件」と「自動継続」をより明確に結びつけ、独立した evaluator によって続行可否を判断します。

日常開発では、この種のコマンドは明確な受け入れ基準を持つエンジニアリングタスクに向いています。要件判断やコードレビューを置き換えるものではありませんが、長いタスクにありがちな「続けて」「もう一度実行して」「テストが通るまで直して」という繰り返しを減らせます。

本当に身につけるべきなのは、コマンドそのものではありません。タスクを、明確で、検証可能で、停止できる目標として書く力です。

参考資料

OpenAI Codex CLI Slash Commands：https://developers.openai.com/codex/cli/slash-commands
Claude Code Goal ドキュメント：https://code.claude.com/docs/en/goal

AI コーディングツールの今回の波で、なぜ DeepSeek がコスト削減の鍵になったのか

Mon, 11 May 2026 04:59:00 +0800

今回の AI コーディングツール競争は、表面上はモデル性能、プラグインエコシステム、agent 自動化の競争に見える。しかし実際に使い始めると、最初にぶつかる問題はコストだ。

Claude Code、Codex、OpenClaw、Superpowers はどれも便利だが、共通点がある。複雑なタスクに入ると、とにかく token を消費する。プロジェクトを読み、計画を作り、ツールを呼び出し、コンテキストを要約し、結果を何度も確認し、場合によっては複数のサブタスクを起動する。モデルが賢くなり、ワークフローが自動化されるほど、請求額も静かに膨らみやすい。

だから今回、DeepSeek が重要になっている。単にコードを書けるからではない。長いコンテキストとキャッシュコストが、AI コーディングツールで最もお金が燃える部分にちょうど効いているからだ。

Agent ツールはなぜ token を大量に消費するのか

従来のチャット型コーディング支援は、基本的に一問一答だ。関数の書き方を聞くと、コード片が返ってくる。この形でも token は消費するが、まだ制御しやすい。

Agent ツールは違う。質問に答えるだけではなく、一時的なエンジニアのようにプロジェクトへ入っていく。

まずディレクトリと重要ファイルをスキャンする；
要件と既存アーキテクチャを理解する；
計画を作る；
ファイルを修正する；
コマンドやテストを実行する；
エラーに応じて修正を続ける；
最後に変更内容をまとめる。

この過程では、モデルが同じコンテキストを何度も読む。プロジェクト説明、コード片、ツール結果、過去の会話、計画、エラーログが繰り返しコンテキストに戻される。少し複雑なタスクになるだけで、数十万 token はすぐに消える。

さらに攻めたプラグインを入れると、コストはもっと目立つ。OpenCode や Claude Code の拡張ツールの中には、デフォルトで agent チームを組むものもある。小さな機能を一つ変えたいだけでも、計画、レビュー、実行、振り返りまで起動することがある。タスクはより「賢く」見えるが、token も増え続ける。

Superpowers の利点は必要なときだけ起動すること

Superpowers のようなツールの利点は、すべてのタスクで完全な agent フローを強制しないことだ。

普段は Claude Code、OpenCode、Codex を従来の方法で動かせる。ブレインストーミング、計画作成、計画実行、振り返りのような skill を明示的に呼び出したときだけ、より重い自動化フローに入る。

これはコスト面で重要だ。

AI コーディングでは、すべてのタスクに重装備を使うべきではない。設定を一行変える、エラーを一つ調べる、小さなスクリプトを書く程度なら、普通の対話で十分だ。複雑なリファクタリング、複数ファイルの変更、長文ドキュメント処理、多段階の検証だけが、完全な agent フローに値する。

ツールが強力になるほど、起動条件を制御する必要がある。そうしなければ、自動化が増えるほど無駄も増える。

DeepSeek の重要な強みはキャッシュが安いこと

DeepSeek がこの種の agent ツールに合う大きな理由は、キャッシュヒット時のコストが低いことだ。

AI コーディングタスクには、大量の反復プレフィックスがある。プロジェクト背景、システムプロンプト、ツール説明、ファイル内容、前の会話ターンは、後続リクエストに何度も現れる。モデルサービスが prompt cache をサポートしていれば、こうした反復部分はキャッシュヒット後にかなり安くなる。

多くのモデルでは、キャッシュヒット価格は未ヒットより少し安い程度で、たとえば三分の一前後という感覚だ。DeepSeek の強みは、ヒット後の価格差がもっと大きくなり得ることにある。長いコンテキスト、多段階呼び出し、プロジェクトの反復読み込みを行う agent ワークフローでは、この差が請求に直接出る。

つまり DeepSeek は、毎回の回答が必ず最強というわけではない。しかし「長いタスク、多いターン、コンテキストの反復読み込み」という場面では、コスト構造が AI コーディングに非常に向いている。

長いコンテキストは Claude Code を使いやすくする

Claude Code や類似ツールを DeepSeek V4 に接続すると、もう一つの明確な利点が長いコンテキストだ。

AI コーディングツールが最も嫌うのは、コンテキスト不足だ。コンテキストが足りなくなると、頻繁に圧縮が必要になる。圧縮が増えると、前に読んだ細部が失われることがある。モデルはプロジェクト構造、制約、あるファイルをなぜ変更したかを忘れ始め、その後の品質が落ちる。

DeepSeek V4 系列の長いコンテキスト能力は、コードリポジトリ、ドキュメントの一括処理、字幕翻訳、サイト記事整理に向いている。特に Claude Code や OpenClaw に接続する場合、設定が適切ならコンテキスト圧縮を遅らせ、より多くのプロジェクト詳細を保てる。

だから DeepSeek で動かすと「よく持つ」と感じるタスクがある。各ステップが必ずしも派手ではなくても、長時間、低コスト、反復呼び出しに耐えられる。

V4 Pro と V4 Flash の分担

DeepSeek V4 Pro と V4 Flash は混ぜて使うべきではない。

単純なタスクには DeepSeek V4 Flash が向いている。速く、安く、次のような場面ではたいてい十分だ。

字幕翻訳；
ドキュメント整理；
普通のスクリプト生成；
小規模なコード修正；
OpenClaw の軽量タスク；
簡単なサイトコンテンツ処理。

複雑なタスクでは DeepSeek V4 Pro を検討する。

大規模リファクタリング；
複数モジュールのコード理解；
複雑な推論；
長い agent チェーンのタスク；
高リスクなコード変更；
より強い計画能力が必要なエンジニアリングタスク。

最初から最強モデルを使いたがる人は多いが、それは割に合わないことも多い。AI コーディングツールの現実的な使い方は、タスクを層に分けることだ。安いモデルに大量の定型作業を任せ、高いモデルは重要な判断点だけに使う。

MiniMax、Doubao、DeepSeek は役割が違う

国内モデルやプランの中で、MiniMax、Doubao、Kimi、DeepSeek にはそれぞれ位置づけがある。

MiniMax の強みは、量が多く、安く、機能が広いことだ。最も賢いコーディングモデルではないかもしれないが、翻訳、軽い整理、一括処理には費用対効果が高い。字幕の一括処理、形式変換、簡単な校正などには、MiniMax 型のプランはかなり使いやすい。

Doubao の強みは、ツールエコシステムが広いことだ。画像、動画、検索、TTS、場合によっては STT や embedding までつなげられる。総合ツールボックスに近い。

DeepSeek の位置づけはもっと明確だ。テキスト、コード、長いコンテキスト、低コストキャッシュ。画像生成、音声、動画の完全なエコシステムはなく、弱点ははっきりしている。しかし AI コーディングと長文 agent ワークフローでは、長所が十分に長い。

だから誰が誰を置き換えるという話ではない。タスクを分け、それぞれに合う道具を使う話だ。

コスト削減の鍵は安いモデルを探すだけではない

AI コーディングでコストを下げるとは、すべてのリクエストを安いモデルに替えることではない。

有効な方法はいくつかある。

単純なタスクで重い agent を起動しない。
Flash で十分なタスクに Pro を使わない。
長いタスクではできるだけキャッシュを使う。
反復コンテキストを安定させ、意味のない変更でキャッシュを無効化しない。
大きなタスクは安いモデルに下書きと一括処理をさせ、強いモデルで重要レビューを行う。
agent に、事実を繰り返し説明せず、同じことを何度も要約しないよう明確に伝える。

特に最後の点は重要だ。AI ツールは冗長になりやすい。冗長さは読みやすさだけでなく、コストの問題でもある。プロンプトに「事実は一度だけ説明し、意見は一度だけ述べる」と入れると、文章品質と token 消費の両方を改善できる。

DeepSeek に向く AI コーディングワークフロー

DeepSeek は次のようなタスクに特に向いている。

長いコードリポジトリの読解；
複数ファイルの軽い修正；
ドキュメントの一括整理；
字幕の一括翻訳；
Hugo 記事の整理；
agent 計画の実行；
大量の反復コンテキストを含む低コスト自動化。

すべてのタスクに向くわけではない。特に強いフロントエンドの審美眼、複雑なプロダクト判断、クロスモーダル制作が必要なら、Claude、GPT、Gemini、Doubao などを組み合わせる必要がある。

しかしタスクが「長文、長いコンテキスト、反復呼び出し、コスト敏感」である限り、DeepSeek は第一候補になりやすい。

まとめ

今回の AI コーディングツールの波で、DeepSeek の価値は「国内モデルがコードを書ける」ことだけではない。agent ツールの最も現実的な痛点、つまり長いタスクが高すぎる問題を解いていることにある。

Claude Code、OpenClaw、Superpowers のようなツールは開発フローをますます自動化する。しかしその裏側には、大量のコンテキスト読み書きと多段階呼び出しがある。この部分のコストを下げられる人が、AI コーディングを「たまに気持ちよく使うもの」から「毎日使えるもの」に変えられる。

DeepSeek の長いコンテキスト、低いキャッシュコスト、V4 Flash / V4 Pro の階層的な使い分けは、まさにその位置にある。

今回の本当のコスト削減の鍵は、良いモデルを使わないことではない。良いモデル、安いモデル、キャッシュ、agent フローをうまく組み合わせることだ。この会計を理解できれば、AI コーディングツールは美しいが高価なおもちゃではなく、本当の生産性になる。

AI Coding プランの選び方：ライトユーザーは使いやすさ、ヘビーユーザーは柔軟性

Sun, 10 May 2026 08:20:58 +0800

AI Coding のプランは、この半年でかなり速いペースで変わっています。多くのツールが「回数ベース」から「使用量ベース」に移行し、無料または低価格プランの枠は締まり、海外サービスの一部では本人確認、地域制限、より厳しい利用ルールも増えました。

開発者にとって問題は、もはや「どのモデルが一番強いか」だけではありません。毎月いくら払うのか、枠は十分か、ツールは使いやすいか、そしてプランが突然値上げされたりルール変更されたりしたときに、スムーズに乗り換えられるかも重要です。

実用的な結論としては、ライトユーザーは使いやすさを買い、中程度のユーザーはコストパフォーマンスを買い、ヘビーユーザーは柔軟性を買うべきです。使い方が重くなるほど、モデルとツールを一つのプランに固定しないほうがよくなります。

プラン選びで見るべき 4 つのポイント

以前の AI Coding プラン選びでは、通常は 3 つのことを見れば十分でした。

モデルの性能が十分に強いか。
応答速度が安定しているか。
プランの枠が足りるか。

今はこれに 4 つ目を加える必要があります。モデルとツールを分けて使えるかどうかです。

モデルは推論能力を担い、ツールはコンテキスト管理、ファイル編集、Agent の編成、ワークフロー体験を担います。どちらも重要ですが、完全に結びつけないほうが安全です。たとえば Claude 系モデルが好きなら公式プランを使ってもいいですし、API を別のツールに接続しても構いません。あるエディタや Agent ツールが気に入っているなら、それが自社モデルしか使えないのではなく、複数モデルをつなげられるかを見たほうがよいです。

ここで大事なのは、複雑にすること自体ではなく、リスクを減らすことです。AI Coding は業界の中でも変化が最も速い分野の一つです。今は枠が緩いプランでも、数か月後には課金方式が変わるかもしれませんし、今は使いやすいツールでも、モデル連携の変更で体験が落ちるかもしれません。モデルとツールを分けておくことは、移行の余地を残すことでもあります。

海外プランは全体として締まりつつある

GitHub Copilot、Cursor、Windsurf、Claude Code のようなツールは今でも多くの人の主力ですが、流れはかなり明確です。安くて枠が大きいプランは維持しにくくなり、使用量ベース課金が一般化しています。

GitHub Copilot のようなサービスが使用量課金を強めるほど、プランそのものの「割安感」は薄くなります。ライトユーザーにはまだ便利ですが、Agent、長いコンテキスト、複雑なコードタスクを高頻度で使う人にとっては、実際の消費は本物の API コストにかなり近づいていきます。

Cursor と Windsurf は、要するにモデル能力を IDE 体験にまとめているツールです。強みは導入のしやすさと成熟したエディタ体験ですが、弱みはツールへのロックインが強めなことです。専用 Agent、インデックス、自動化フローに依存するほど、後から移るコストは高くなります。

Claude Code は体験面でも注目度でも魅力がありますが、海外サブスクリプション、本人確認、地域制限、中継サービスの安全性は、中国国内のユーザーにとって無視できないリスクです。特に第三者の中継サービスは、モデルの混在、安定性不足、データ安全性、サービス終了といった問題を抱えやすく、重要な仕事の長期基盤には向きません。

国内プランの強みと弱み

国内の AI Coding プランの利点は、多くが API 形式で提供されているため、特定のツールに強く縛られにくいことです。OpenCode、Cline、Continue、自作スクリプト、社内 Agent などに接続できます。

一方で弱点もはっきりしています。モデルが強く、速く、枠も大きい、という条件を同時に満たすプランはあまり多くありません。

GLM 系は国内モデルの中では強い部類ですが、ピーク時間帯にはスループットが不安定になり、重いタスクでは速度が足かせになることがあります。Kimi も能力は高いですが、価格と枠のルールは継続的に確認が必要で、特にバックエンドの枠がどれだけ透明かが重要です。MiniMax のようなモデルは速度と枠の面では使いやすく、日常の軽いタスクやバッチ処理、比較的単純なコード支援に向いていますが、難しいエンジニアリング推論では一段落ちることがあります。DeepSeek の新モデルは、キャンペーン価格のうちは非常にコスト効率が高く見えることがありますが、終了後は通常価格で改めて評価し直す必要があります。

そのため国内プランは、一つの万能パッケージとして使うより、「モデルプール」として運用したほうが向いています。タスクごとにモデルを使い分けるほうが現実的です。

ライトユーザー：使いやすさを優先し、API 構築にこだわりすぎない

週に数回、AI にスクリプト修正、ドキュメント補完、エラー説明、小さなツール作成を頼む程度なら、複雑な構成は不要です。

このタイプのユーザーは、まず使いやすい製品を選ぶのが正解です。Cursor、Windsurf、Trae、CodeBuddy、通義霊碼、GitHub Copilot などはどれも試す価値があります。大切なのは最安値ではなく、摩擦が少ないことです。普段使うエディタで安定して動き、補完品質が悪くなく、失敗したときに戻しやすい。それで十分です。

少し安くするためだけに、多段の API、中継、複雑なプロキシ構成を組むのは、ライトユーザーにはあまりおすすめできません。時間コスト、アカウントリスク、トラブル対応の手間のほうが、節約額より大きくなりがちです。

中程度のユーザー：コスパだけでなく、移行しやすさも見る

毎日 AI を使ってコードを書き、プロジェクトを直し、テストを作り、ドキュメントを整理するようになると、枠と実際の消費量をより真剣に見る必要が出てきます。

このタイプのユーザーには、主力ツールと予備モデルを分けておく構成が向いています。たとえば、使いやすい IDE プランで日常の編集を行い、別に複数ツールへ接続できる API や集約プランを用意して、長いコンテキストや複雑な Agent タスクに使う、といった形です。

選ぶときに見るべきポイントは主に 3 つです。

外部ツールへ接続できるか。
token や枠の消費が見えるか。
超過時の挙動が、速度制限、機能劣化、停止、純粋な従量課金のどれか。

見た目は安くても、そのツールの中でしか使えないプランなら、移行コストまで含めて考える必要があります。逆に少し高くても複数ツールで使えるなら、長期的にはそちらのほうが主力に向く場合があります。

ヘビーユーザー：モデルとツールを固定しない

ヘビーユーザーにとっての核心は柔軟性です。

個人やチームが毎日大量に AI Agent を使うようになると、消費量はすぐ大きくなります。コードベース検索、長いコンテキストでの修正、多段のデバッグ、自動テスト修復などは、token 消費を一気に増やします。その状態で単一プランに依存すると、次の 3 つの問題が起きやすくなります。

枠が急に足りなくなる。
課金ルールが突然変わる。
あるツールやモデルが一時的に使えなくなる。

より安定したやり方は、層を分けた構成にすることです。主力 Agent ツールを一つ、差し替え可能なモデル接続先を一つ以上、軽い仕事をさばく低コストモデルを一つ、難しい仕事を担う高性能モデルを一つ、という形です。日常の軽い仕事を全部いちばん高いモデルに投げる必要はありませんし、重要な仕事を最安モデルだけに頼るのも危険です。

ヘビーユーザーにとっては、「どのツールにもモデルをつなげられる」「どのモデルも別ツールで使える」という柔軟性のほうが、月数十ドルの差額より重要です。本当に高いのはサブスク料金そのものではなく、一つのエコシステムに閉じ込められたあとで、ワークフローを作り直すコストだからです。

より安定した組み合わせ方

比較的安定した構成は、次のように考えられます。

軽いタスクは低コストモデルに任せる。コード説明、小さなスクリプト、整形、簡単な文書生成など。
中程度のタスクはコスパ重視モデルに任せる。通常の機能開発、テスト補完、リファクタリング提案など。
難しいタスクは強いモデルに任せる。複雑な設計変更、複数ファイルの修正、難しいバグ、長いコンテキスト推論など。
ツール層は開いておく。API 接続、設定の持ち出し、モデル切り替えができるツールを選ぶ。
予備ルートを残す。主力プランのルールが変わったときに、別のモデルやツールへすぐ切り替えられるようにする。

これが最安とは限りませんが、変化にはかなり強くなります。AI Coding の価格や枠は今後も変わり続けるはずです。長期的に価値があるのは、短期的にお得に見えるプランそのものではなく、持ち運びできるワークフローです。

まとめ

AI Coding のプランは、月額だけで判断すべきではありません。ライトユーザーはシンプルさと使いやすさを優先し、中程度のユーザーは枠、消費量、移行しやすさを見て、ヘビーユーザーはモデルとツールを切り離して単一エコシステムへの依存を避けるべきです。

覚えておきたいのは、プランもモデルもツールも変わる、ということです。選択権を自分の手元に残しておくことが、長く AI Coding を使ううえで最も重要なコスト管理になります。

Claude Code の制限が倍増：Anthropic が SpaceX の計算資源拡張で利用制限を緩和

Sat, 09 May 2026 10:59:48 +0800

Anthropic は 2026 年 5 月 6 日、Claude Code と Claude API の利用上限を引き上げ、SpaceX と新たな計算資源提携を結んだと発表しました。一般ユーザーにとって最も直接的な変化は、Claude Code で使える容量が増えることです。開発者や企業にとっては、Claude の推論容量がさらに拡大している点が重要です。

今回の発表は 2 つに分けて見ると分かりやすいです。

Claude Code と Claude API の制限引き上げ。
SpaceX のデータセンターから得る新しい計算資源。

Claude Code の制限はどう変わったか

Anthropic によると、発表当日から次の 3 つの変更が有効になりました。

Pro、Max、Team、seat-based Enterprise プランで、Claude Code の 5 時間 rate limit が倍増。
Pro と Max アカウントに対する Claude Code のピーク時間帯の制限引き下げを廃止。
Claude Opus モデルの API rate limits を大幅に引き上げ。

つまり、Claude Code を長時間のコーディング、リポジトリ分析、リファクタリング、デバッグ、Agent ワークフローに使っている場合、作業途中で制限に達する場面が減る可能性があります。

ただし、制限引き上げは無制限利用を意味しません。Claude Code は引き続き、契約プラン、利用方法、モデル、タスクの長さ、コンテキストサイズ、プラットフォームポリシーの影響を受けます。それでも、以前より明確に利用余地が広がったと言えます。

なぜ計算資源が Claude Code 体験に影響するのか

Claude Code のようなツールは、通常のチャットより多くのリソースを使います。1 つのコーディングタスクでも次のような処理が含まれることがあります。

多数のファイル読み込み。
長いコンテキストの分析。
複数回のツール呼び出し。
コードの生成、編集、確認。
テスト実行やエラー説明の繰り返し。
複雑な推論に Opus モデルを使うこと。

これらの操作で消費されるのは token だけではありません。モデル推論容量、同時実行能力、スケジューリング資源も必要です。ユーザーには「制限」「待ち行列」「ピーク時の遅さ」として見え、プラットフォーム側では計算資源の供給と需要の圧力として見えます。

そのため、Anthropic が制限引き上げと計算資源提携を同じ発表に入れたことには意味があります。Claude Code の体験改善は、単にプラン設定を変えるだけではなく、バックエンドの推論容量拡張に依存しているということです。

SpaceX との提携で何が増えるのか

Anthropic は SpaceX と契約し、SpaceX Colossus 1 データセンターの全計算容量を利用すると述べています。公式発表では、この容量は 300 メガワット超で、22 万基以上の NVIDIA GPU に相当し、1 か月以内に Anthropic が利用可能になるとされています。

この追加容量は、Claude Pro と Claude Max 加入者の利用可能容量を直接改善するとされています。

発表では、将来的に SpaceX と軌道上 AI 計算資源の開発で協力することにも関心を示しています。ただしこれは長期的な方向性であり、ユーザーがすぐに感じる Claude Code の制限引き上げとは別の話です。

Anthropic の計算資源展開は大きくなっている

SpaceX は Anthropic の最近の計算資源拡張の一部にすぎません。公式発表では他の提携も挙げられています。

Amazon との最大 5GW の提携。うち約 1GW の新容量は 2026 年末までに稼働予定。
Google と Broadcom との 5GW の提携。2027 年から稼働開始予定。
Microsoft と NVIDIA との戦略提携。300 億ドルの Azure 容量を含む。
Fluidstack との 500 億ドル規模の米国 AI インフラ投資。

Anthropic は、Claude の学習と推論に AWS Trainium、Google TPU、NVIDIA GPU など複数の AI ハードウェアを使うとも説明しています。

この傾向は明確です。主要モデル企業の競争は、モデル名、ベンチマーク、製品機能だけではありません。電力、データセンター、GPU、TPU、ネットワーク、グローバル展開能力も競争領域になっています。

Claude Code ユーザーへの実際の影響

開発者にとって最も注目すべき変化は、Claude Code の 5 時間制限が倍増したことです。これは次のような場面に影響します。

大規模リポジトリのコード読解。
複数ファイルのリファクタリング。
バグ調査とテスト修正。
コード移行と依存関係アップグレード。
長時間の Agent コーディングタスク。
Team や Enterprise で複数人が同時に Claude Code を使う場合。

これまで Claude Code では、タスクが進行中なのに上限に達することがよくありました。制限が上がれば、Agent が途中で止まらず 1 つのタスクを最後まで進めやすくなります。

Pro または Max ユーザーにとっては、ピーク時間帯の制限引き下げ廃止も重要です。混雑する時間帯でも体験が安定しやすくなり、一時的な制限強化で Claude Code のワークフローが大きく妨げられる可能性が下がります。

API ユーザーにとっての意味

発表では、Claude Opus モデルの API rate limits も大幅に引き上げられたとされています。Opus を複雑なタスクに使うチームにとって、通常これは次のような意味を持ちます。

より高い同時実行。
429 レート制限エラーの減少。
バッチ処理を支えやすくなる。
長いコンテキスト、複雑な推論、Agent ワークフローにより適する。

ただし具体的な上限は、アカウント、組織、モデル、プランによって異なります。本番導入前には、自分の Anthropic Console、rate limits ドキュメント、エラーログを確認する必要があります。

企業と地域展開も重要になる

Anthropic は、金融、医療、政府などの規制業界では、コンプライアンスとデータ所在要件を満たすために地域内インフラがますます必要になるとも述べています。そのため、容量拡張の一部は米国外、特にアジアと欧州の推論能力に向けられます。

これは企業顧客にとって重要です。大規模モデルアプリケーションが中核業務に入ると、問題は「モデルが使いやすいか」だけではありません。

データが指定地域に留まるか。
業界のコンプライアンス要件を満たせるか。
ピーク時に安定した容量があるか。
チーム単位、組織単位の同時利用を支えられるか。
監査、権限、安全制御があるか。

この観点では、計算資源の拡張は単なる性能ニュースではありません。企業の調達や導入判断にも影響します。

まとめ

Anthropic の今回のメッセージは明確です。新しい計算容量がオンラインになるため、Claude Code と Claude API の利用制限が緩和されています。

一般的な Claude Code ユーザーにとって重要なのは、5 時間制限の倍増と、Pro、Max のピーク時間帯制限引き下げ廃止です。API と企業ユーザーにとっては、Opus rate limits の引き上げと、SpaceX、Amazon、Google、Microsoft、NVIDIA、Fluidstack との長期的な計算資源戦略が重要です。

AI ツールはますますインフラサービスに近づいています。モデル能力は一部にすぎません。安定した容量、地域コンプライアンス、制限ポリシー、コスト管理もユーザー体験を決めます。

参考リンク：

Anthropic：Higher usage limits for Claude and a compute deal with SpaceX

Claude アカウントが停止されたら？Claude Code 制限の原因と異議申し立てガイド

Sat, 09 May 2026 10:32:12 +0800

Claude または Claude Code の account が突然制限される、支払い直後に停止される、Pro 権限が反映されない、利用量が急に少なく見える。このような問題は最近よく話題になる。重要なのは、これを単純に「IP を変えればよい」「別 account を作ればよい」という技術問題として扱わないことだ。account risk system は通常、region、payment、device、login behavior、usage content、automation、sharing pattern など複数の signal を組み合わせて判断する。

より安全な対応は、自分が遭遇している問題をまず分類することだ。通常の quota limit なのか、payment/subscription mismatch なのか、Claude Code authorization issue なのか、それとも Anthropic が policy または terms 違反と判断した account-level action なのかを分ける。

まず三つの状況を分ける

第一は通常の利用上限である。Claude Pro、Max、Team、API、Claude Code は quota model が異なる。peak hour、long context、coding task、agent workflow は limit を早く消費することがある。「limit reached」が出ても、必ずしも account ban ではない。

第二は subscription または authorization の異常である。支払いは成功したが権限が更新されない、mobile subscription と web account が一致しない、Claude Code が正しく login していない、環境変数に古い ANTHROPIC_API_KEY が残っている、といったケースがある。まず billing、login state、client configuration を確認する。

第三が account suspension または termination である。suspension、disabled、terminated といった email を受け取る、または login 時に account unavailable と表示される場合がこれに近い。この場合、device、network、account を次々変えて再試行しないほうがよい。risk signal をさらに複雑にする可能性がある。

よくある trigger

Anthropic の help document と privacy document では、Usage Policy 違反、unsupported region からの account 作成または利用、terms 違反、繰り返しの違反、異常 access、abuse などが risk area として挙げられている。

実際の利用で risk になりやすい場面は次の通り。

account registration、login region、payment region が一致しない。
datacenter proxy、shared proxy、頻繁な IP switching を長期利用する。
複数人で一つの personal account を共有する。
短時間に多くの device や region から login する。
Claude.ai へ high-frequency automation で access する。
Claude Code を shared service や resale entry point として扱う。
Anthropic の policy に明確に反する content を要求する。
payment method、billing address、account region が衝突する。

一つの signal が必ず suspension につながるわけではない。複数の abnormal signal が重なると、account が high risk と判断されやすくなる。

risk control を回避する発想で解決しない

ネット上では、fingerprint browser、device fingerprint reset、local folder 削除、environment 変更、time zone/language の固定、新しい email での再登録などを「安定利用策」として紹介することがある。その一部は普通の troubleshooting だが、一部は明らかに platform risk control の回避を狙っている。

「risk control bypass」を解決策にするのは勧めない。理由は単純だ。

terms of service に違反する可能性がある。
account risk signal をさらに増やす可能性がある。
payment、region、policy violation といった根本原因を解決しない。
team または business use の場合、後の appeal で説明しにくくなる。

Claude を長期的に安定して使いたいなら、正しい方向は偽装ではない。account information、region、payment、device、usage をできるだけ真实で、一貫し、説明可能にすることだ。

Claude Code 制限の確認

Claude Code ユーザーは、まず次を確認する。

1
2

claude --version
claude auth status

API key を使っている場合は、環境変数が正しい account を指しているか確認する。

`1`	`echo $ANTHROPIC_API_KEY`

Windows PowerShell では次を使う。

`1`	`echo $env:ANTHROPIC_API_KEY`

web login、OAuth、API key、third-party client、異なる terminal を併用していた場合は、まず authentication method を統一する。一部の tool が古い credential を使い続けていることがある。

また、次の二つを分ける。

Claude Code の usage limit に達した：通常は quota または subscription の問題。
account または organization が disabled：通常は account、organization、payment、policy risk の問題。

前者は quota refresh を待つか plan を調整する。後者は screenshot と email を保存し、official support または appeal channel を使う。

compliant に安定利用するための注意

account 異常の可能性を下げたいなら、まず基本を整える。

supported country/region の normal account を使う。
login region、payment method、billing information をできるだけ一致させる。
personal account を複数人で共有しない。
personal Pro/Max を team API pool として使わない。
IP、device、browser environment を頻繁に切り替えない。
出所不明の third-party Claude client を使わない。
Claude.ai の web interface に対して high-frequency automation をしない。
business/team use では Team、Enterprise、API を優先する。
Anthropic Usage Policy を理解し、restricted use に使わない。

複数 device で使う必要があるなら、通常通り login すればよい。environment を頻繁に消したり、fingerprint を変えたり、proxy を切り替えたりしない。過度な environment manipulation 自体が abnormal behavior に見える可能性がある。

停止後にやること

account がすでに suspended された場合は、次の順序で対応する。

Anthropic または Claude からの email を確認し、理由または message type を把握する。
新しい account 作成、network 変更、device 変更を繰り返さない。
account email、subscription order、payment proof、recent usage context を整理する。
誤判定だと思う場合は、official entry から appeal を提出するか support に連絡する。
real usage scenario を説明し、region、identity、purpose を作らない。
subscription charge が関係する場合は、refund または subscription handling を別途問い合わせる。

appeal では具体性が重要だ。Claude Code を使ったか、device を切り替えたか、VPN を使ったか、team sharing があったか、third-party tool を接続したかを説明する。platform は risk source を判断する必要がある。「何もしていない」という曖昧な説明だけでは効果が薄い。

注意して読むべき主張

「fingerprint を固定すれば ban されない」「特定 browser で完全に防げる」「ある directory を消せば device identity が reset される」「IP と time zone を合わせればすべて解決する」といった主張がある。これらはそのまま信じないほうがよい。

platform risk control は通常 multidimensional であり、browser fingerprint や IP だけを見ているわけではない。account history、payment information、region policy、usage content、access frequency、automation pattern、client version、API call behavior などが関わる。単一 signal の disguise は長期安定ではなく、不一致を増やすことがある。

さらに、多くの「anti-ban solution」は実質的には tool や service の販売である。ユーザーに必要なのは risk source の判断、compliant use、appeal evidence の保存であり、third-party environment wrapper に account safety を預けることではない。

まとめ

Claude account suspension や Claude Code limitation は、必ずしも単一原因ではない。quota、subscription、authorization の問題かもしれないし、region、payment、device、sharing、automation、content policy が組み合わさった risk control かもしれない。

Claude を長期的に安定して使う鍵は、risk control を回避することではない。compliant usage、account information の一貫性、stable access pattern、team use の正式 plan である。停止された場合は、environment をいじるのを止め、evidence を保存し、official appeal と support channel を使うのが最も安全だ。

参考リンク：

PPTからプロトタイプ設計まで：Guizang PPT SkillとHuashu Designの使いどころ

Sat, 09 May 2026 08:34:23 +0800

最近、中国語圏の開発者が作った2つのデザイン系 Agent Skill は、並べて見る価値があります。ひとつは歸藏による guizang-ppt-skill、もうひとつは花叔による huashu-design です。

どちらも従来の意味での「デザインツール」ではありません。設計プロセス、審美上の好み、チェックリスト、エンジニアリングテンプレートを、Agent が実行できる Skill として記述したものです。UI を開いて要素を少しずつドラッグするのではなく、Claude Code、Codex、Cursor のような Agent に要件を渡し、決められた流れに沿って HTML、PPT、アニメーション、プロトタイプを生成させます。

この種のプロジェクトの価値は、AI にランダムに発想させることではありません。「どう作れば見苦しくならないか」をプロセス化している点にあります。

guizang-ppt-skill：雑誌風Web PPTに特化

歸藏の guizang-ppt-skill は位置づけが明確です。単一ファイルの HTML 横スクロールPPTを生成し、視覚の基調は「デジタル雑誌 x 電子インク」です。汎用デザインフレームワークというより、登壇用に用意されたレイアウトシステムに近い存在です。

リポジトリの README では、主な機能として次のものが挙げられています。

単一ファイル HTML 出力。ビルドもサーバーも不要で、ブラウザから直接開ける。
横方向のページ移動。キーボード、ホイール、タッチスワイプ、下部ドット、ESC インデックスに対応。
Ink Classic、Indigo Porcelain、Forest Ink、Kraft Paper、Dune を含む5種類のテーマカラープリセット。
オープニングカバー、章区切り、データ大見出し、左テキスト右画像、画像グリッド、Pipeline、サスペンス質問、大きな引用、Before/After 比較、テキスト画像混在など10種類のページレイアウト。
テンプレート、コンポーネント説明、レイアウト骨格、テーマ設定、品質チェックリストを内蔵。

オフライン共有、業界内の社内発表、少人数イベント、AIプロダクト発表、demo day、そして強い個人スタイルを持つプレゼン資料に向いています。一方で、大量の表データ、研修教材、複数人での共同編集にはあまり向きません。

このプロジェクトの良いところは、割り切りです。すべてのデザイン場面を覆おうとせず、「雑誌風PPT」という場面を狭く定義しています。テーマ色はプリセットから選び、レイアウトにも明確な骨格があります。その制約が、むしろ Agent の脱線を減らします。

意見、業界観察、プロダクト発表の内容をプレゼン deck にまとめる機会が多いなら、かなり実用的です。

インストールコマンドも単純です。

`1`	`npx skills add https://github.com/op7418/guizang-ppt-skill --skill guizang-ppt-skill`

huashu-design：より包括的なHTMLネイティブ設計ワークフロー

花叔の huashu-design はカバー範囲がより広いです。目標は PPT だけを作ることではなく、HTML をネイティブなデザインキャンバスとして扱い、Agent に納品可能なデザイン資産を生成させることです。

リポジトリの README では、次のような機能が挙げられています。

クリック可能な App または Web プロトタイプ。
HTML スライド、および編集可能な PPTX エクスポート。
プロダクト発表アニメーション、MP4、GIF、音楽付きバージョン。
複数方向のデザイン案の横並び比較。
インフォグラフィック、データ可視化、PDF、PNG、SVG エクスポート。
哲学的一貫性、視覚階層、実行品質、機能性、革新性を含む5次元の専門家レビュー。

中心にある考え方は、Agent にまずブランドと素材を理解させ、その後で高忠実度のデザインを出させることです。プロジェクトでは Core Asset Protocol が強調されています。具体的なブランドを扱うときは、記憶に頼って推測するのではなく、logo、製品画像、UI スクリーンショット、配色、フォント、ブランドガイドラインを先に確認します。

これは重要です。AI が生成したデザインの多くは「デザインっぽく」は見えますが、特定の実在する製品やブランドには見えません。huashu-design はこの問題を前段で解決しようとします。まず本物の素材を見つけ、それからデザインする、という流れです。

インストールコマンドは次のとおりです。

`1`	`npx skills add alchaincyf/huashu-design`

より包括的なデザイン納品をターミナル内で進めたい人に向いています。製品プロトタイプ、発表アニメーション、プレゼン資料、インフォグラフィック、デザインレビューを、ひとつの Agent ワークフローに載せて処理できます。

両者の最大の違い

簡単に言えば、guizang-ppt-skill はより狭く、より安定したプレゼン deck 生成器です。huashu-design はより広く、より包括的な HTML ネイティブ設計システムです。

PPT だけを見るなら：

guizang-ppt-skill は雑誌感、リズム、版面、単一ファイルのブラウザ発表をより重視します。
huashu-design は汎用的なデザイン能力、編集可能な PPTX、ブランド素材、エクスポート経路、レビュー工程をより重視します。

全体的なデザイン能力を見るなら：

guizang-ppt-skill は境界が明確で、スタイルのある横型プレゼンを素早く作るのに向いています。
huashu-design はより総合的で、製品やブランドのデザインタスクをプロトタイプ、アニメーション、スライド、インフォグラフィックに分解するのに向いています。

この2つのプロジェクトは、Skill の書き方としても異なる型を示しています。前者は高度に収束したテンプレートと審美上の制約の集合に近く、後者は小さなデザインチームのワークフロー説明書に近いものです。

なぜこの種のSkillが重要なのか

Agent でよくある問題は、「できるが、安定しない」ことです。同じ要件でも、あるときは良い出力になり、別のときは紫のグラデーション、角丸カード、偽物のアイコン、もっともらしい空文句へ流れてしまうことがあります。

Skill の意義は、そこに安定性を補うことです。次のようなものを固定化できます。

再利用可能なテンプレート。
実行可能なチェックリスト。
明確な審美上の好み。
よくあるミスを避けるルール。
出力形式と検証フロー。
いつ質問し、いつそのまま作業を始めるべきか。

これは、単に「もっと高級感を出して」と書くよりはるかに信頼できます。

特にデザインタスクでは、審美は一文の prompt だけで安定して再現できるものではありません。本当に役に立つのはプロセスです。まず素材を確認し、方向性を決め、構造を組み、視覚表現を作り、最後に出力を確認する。この流れを Skill として書くことで、Agent は一回きりの画像生成器ではなく、協働できる実行者に近づきます。

使い分けの提案

ひとつのテーマをオフライン登壇や共有用の deck にしたいだけなら、まず guizang-ppt-skill を試すとよいでしょう。出力の境界が狭く、単一ファイル HTML なので配布やプレビューもしやすいです。

Agent により包括的なデザインタスクを任せたい場合、たとえば App プロトタイプ、発表アニメーション、ブランド化されたスライド、エクスポート可能な PPTX、インフォグラフィックなどであれば、まず huashu-design を見るとよいでしょう。ワークフローは長めですが、複数回の反復と納品物の出力が必要なタスクに向いています。

すでに自分の Codex や Claude Code Skill を書いているなら、この2つのプロジェクトはいずれも参考になります。

「狭い場面をどう安定させるか」を学びたいなら、guizang-ppt-skill。
「複雑なワークフローをどう実行可能なプロトコルに分解するか」を学びたいなら、huashu-design。

まとめ

歸藏と花叔の2つのプロジェクトに共通しているのは、「デザイン能力」を一回の prompt から、繰り返し実行できるプロセスへ変えていることです。

guizang-ppt-skill の重点は雑誌風 HTML PPT で、強くスタイル化されたプレゼンに向いています。huashu-design の重点は HTML ネイティブ設計システムで、プロトタイプ、アニメーション、スライド、インフォグラフィック、レビューまでをカバーします。解決しているのは「AI はデザインを生成できるか」ではなく、「AI は安定した方法に沿って納品可能なデザインを生成できるか」です。

これは Agent ツールのエコシステムにおいて、重要なオープンソースプロジェクトの一類型になるかもしれません。コードテンプレートだけでなく、人間の経験、審美、仕事の進め方を Skill としてパッケージ化するものです。

参考リンク：

Codex vs Claude Code：2 つの Subagent 設計をどう選ぶか

Fri, 08 May 2026 14:14:01 +0800

AI コーディングツールでは Subagent が重要になっています。これは流行りの機能ではなく、単一 Agent が実際の開発タスクを抱え込むと限界に当たりやすいからです。

1 つの Agent がコードを読み、ログを確認し、実装を変更し、テストを実行し、エラーを分析し、結果をまとめると、main context はすぐ汚れます。検索結果、コマンド出力、テストログ、中間推論が混ざり、後の判断が不安定になります。探索、実装、検証、レビューを 1 本の main thread に押し込むため、並行処理もしづらくなります。

Subagent の本質は Agent の負荷を下げることです。main session はすべてを最後まで行うのではなく、目標を決め、タスクを割り当て、結果を受け取り、最終回答へ統合する coordinator になります。Subagent は探索、実装、検証、レビューなど局所的な仕事を処理し、圧縮した結論を返します。

つまり Subagent は「もう 1 人の自分」ではなく、絡み合った開発作業を明確な役割に分ける仕組みです。

共通する土台

成熟した Subagent system には通常、次の要素が必要です。

Context isolation。
Role specialization。
Project/user level configuration。
Tool and permission boundaries。

Context isolation は前提です。実際のリポジトリでは、検索結果、テストログ、コマンド出力など中間情報が大量に出ます。これをすべて main session に入れると main thread が乱れます。Subagent は局所的な過程を先に消化し、判断に必要な signal だけを返します。

Role specialization も重要です。複数 Agent とは同じモデルを複数起動することではありません。探索役は検索、読解、要約に強くあるべきです。実装役はコード変更に集中します。検証役はチェックを実行し、リスクを見つけ、結果を明確に報告します。

Tool と permission の境界は安全性を決めます。Subagent が main session の全能力を自動継承すべきではありません。読み取り専用の explorer に書き込み権限は不要です。verifier が実装を変更する必要もありません。

Codex と Claude Code はこの問題意識を共有しつつ、異なる道を取っています。

Codex：明示的な委任

Codex の Subagent 設計は抑制的です。

現在の main session を中心に、制御された軽量な分業機構を提供します。いつ委任するか、誰に渡すか、いつ結果を受け取るかは明示的な判断です。制御フローは現在のタスクに残ります。

特徴は次の通りです。

main session が明示的に subtask を委任する。
role set は小さく保たれる。
main session は誰が何をしているか把握できる。
結果は main line に戻ってから判断される。
協作境界が透明。

これは手動 orchestration、予測可能性、実行の確定性を重視するチームに向いています。explorer に call chain を調べさせ、worker に限定的な変更を任せ、main session が結果を統合して次のテストを判断できます。

一方で、分割、委任、回収、統合の負荷は main session に残ります。軽量な協作には心地よいですが、長期的で複雑な workflow では重くなることがあります。

Claude Code：Agent を workstations として扱う

Claude Code はより platform 的です。

Agent を、説明可能、選択可能、設定可能、記憶可能、隔離可能、background 実行可能な正式な object として扱います。Subagent は会話中の一時的な helper ではなく、開発システムの workstation に近い存在です。

Agent list、use case、description、tool boundary をモデルに渡し、モデル自身がその turn に適した role を選ぶことができます。これにより委任はより自動化されます。

この方向性を支える要素はいくつかあります。

第一に role system。explorer、planner、general-purpose、verifier などの role が用途説明、tool restriction、default model、runtime condition を持てます。read-only explorer は編集できず、planner は設計に集中し、verifier は検証に集中します。

第二に inheritance と override。Subagent は完全に自由ではありません。main session の大きな境界を継承しつつ、許可された範囲で局所的に振る舞いを調整します。

第三に memory。memory は単に少し覚えることではなく、scope を持ちます。user memory は長期的な好み、project memory はリポジトリ背景、local memory は現在環境の状態です。

第四に background work と worktree isolation。検証 task は background で走り続けることができ、main thread は待ち続けなくて済みます。強い隔離が必要なときは別 worktree で作業できます。

第五に plugin ecosystem。Agent を first-class object と見るなら、配布、インストール、優先順位、override、安全境界を考える必要があります。plugin agent は入れられますが、permission mode、hooks、MCP servers など高リスク領域は制限されるべきです。

これにより Claude Code は単発 session の協作ツールではなく、Agent runtime に近く見えます。

違い

Codex は制御された分業ツールに近いです。

明示的な委任。
軽量な role set。
明確な制御フロー。
現在 session 中心の subtask。
人が orchestration する確定的な作業に向く。

Claude Code は engineering workstation system に近いです。

Agent が正式に model 化される。
role が体系化される。
memory、background、isolation、plugin が runtime に含まれる。
モデルが role 選択に関与できる。
長期 project や platform 的 workflow に向く。

問題は機能数ではありません。Subagent を「自分が明示的に呼ぶ helper」と見るか、「system に長期存在する workstation」と見るかです。

選び方

明示的な制御、軽量な分業、現在 session 内の安全な並行処理を重視するなら Codex 的な設計が合います。コードレビュー、小さな変更、明確な実装 task、人がリズムを握りたい workflow に向きます。

体系化された role、長期 memory、background execution、worktree isolation、plugin extension、より完全な Agent runtime を求めるなら Claude Code 的な設計が合います。

判断する質問は 2 つです。

モデル自身が誰に仕事を任せるか選ぶことを受け入れられるか。
より完全な Agent runtime が必要か。

1 つ目が不安なら明示的委任が向いています。2 つ目が yes なら、platform 的な workstation system が向いています。

使い方の注意

Subagent を「モデルを増やせば強くなる」と考えない方がよいです。

各 role の task boundary を明確にする。
role ごとの tool を制限する。
raw log ではなく結論を返させる。
最終判断は main session に残す。
background task と worktree isolation を可視化する。
plugin agent に安全境界を置く。

Subagent の価値は数ではなく分業品質です。role が明確で context がきれいなほど、main thread の判断は安定します。

まとめ

Codex と Claude Code は同じ問題に向き合っています。単一 Agent は実際の開発作業をすべて背負いにくい。両者とも context isolation、role specialization、permission boundary、local summarization を重視します。

違いは設計の方向です。Codex は抑制的で、明示的委任と main session の制御を重視します。Claude Code は体系的で、Agent を設定、記憶、隔離、background 実行、plugin ecosystem に対応した正式な workstation として扱います。

選択はブランド勝負ではありません。必要なのが制御された協作ツールなのか、完全な Agent runtime なのかで決まります。

9Router：Claude Code、Codex、Cursor を 1 つの AI ルーターにつなぐ

Fri, 08 May 2026 13:41:15 +0800

9Router は AI コーディングツール向けのローカルルーターです。Claude Code、Codex、Cursor、Cline、Copilot、OpenCode、OpenClaw などを 1 つの OpenAI-compatible endpoint に接続し、そこから複数のモデルや provider に転送します。

目的はチャットクライアントを増やすことではありません。AI コーディングツールとモデル provider の間に入り、API 形式の違い、provider の手動切り替え、ツール出力による token 消費、quota 切れ、複数アカウント管理をまとめて扱います。

README によると、9Router は 40 以上の provider と 100 以上のモデルに対応し、RTK Token Saver、自動 fallback、quota 追跡、複数アカウントのローテーション、形式変換、リクエストログを備えています。JavaScript 製で、Node.js、Next.js、React、Tailwind CSS、LowDB を使い、MIT ライセンスです。

何に向いているか

複数の AI コーディングツールと複数のモデル供給元を同時に使う場合に便利です。

Claude Code はサブスクリプションで使う。
Codex や Cursor にカスタム OpenAI endpoint を設定したい。
Cline、Continue、RooCode に OpenAI-compatible API を渡したい。
無料 provider を試用に使う。
GLM、MiniMax、Kimi などを安価なバックアップにする。
高品質モデルを難しいタスクだけに使う。

通常は各ツールに endpoint、API key、モデル名、fallback を個別設定する必要があります。9Router はそれをローカルのルーティング層に集約します。

API:

`1`	`http://localhost:20128/v1`

Dashboard:

`1`	`http://localhost:20128/dashboard`

インストール

ローカル利用なら npm が簡単です。

1
2

npm install -g 9router
9router

ソースから実行する場合：

git clone https://github.com/decolua/9router.git
cd 9router
cp .env.example .env
npm install
PORT=20128 NEXT_PUBLIC_BASE_URL=http://localhost:20128 npm run dev

本番起動：

1
2

npm run build
PORT=20128 HOSTNAME=0.0.0.0 NEXT_PUBLIC_BASE_URL=http://localhost:20128 npm run start

npm パッケージは Node.js >=18.0.0 を要求します。VPS や Docker では JWT_SECRET、INITIAL_PASSWORD、DATA_DIR、API_KEY_SECRET を設定してください。

ツールの接続

一般的な設定：

1
2
3

Base URL: http://localhost:20128/v1
API Key: 9Router Dashboard からコピー
Model: 9Router で設定したモデル名または combo 名

Codex CLI:

export OPENAI_BASE_URL="http://localhost:20128"
export OPENAI_API_KEY="your-9router-api-key"

codex "your prompt"

Cline、Continue、RooCode では OpenAI Compatible を選びます。

1
2
3

Base URL: http://localhost:20128/v1
API Key: your-9router-api-key
Model: cc/claude-opus-4-7

モデル名は接続済み provider によって変わり、cc/、cx/、gh/、glm/、minimax/、kr/、vertex/ などがあります。

RTK Token Saver

AI コーディングでは以下のようなツール出力が token を大きく消費します。

git diff
git status
grep
find
ls
tree
ログ
長いファイル一覧

9Router の RTK Token Saver は、これらをモデルに送る前に圧縮します。プロジェクト説明では、多くのリクエストで 20%-40% の input tokens を節約できるとされています。

ただし、重要なログや完全なファイル内容が必要な場面では、圧縮が回答品質に影響しないか確認してから使うのが安全です。

自動 fallback

モデルを優先順に並べられます。

1
2
3

1. サブスクリプションモデル
2. 安価な API
3. 無料 provider

例：

1
2
3

1. cc/claude-opus-4-7
2. glm/glm-5.1
3. kr/claude-sonnet-4.5

fallback は作業停止を減らしますが、モデルが変わると出力の一貫性も変わります。大規模リファクタリングや移行では固定モデルを使う方が安全です。

無料 provider の注意点

Kiro、OpenCode Free、Vertex などの無料経路は便利ですが、利用条件、地域制限、サードパーティツールでの利用可否、ban や rate limit、期限を必ず確認してください。9Router はルーティングを管理するだけで、上流 provider の規約は変えません。

デプロイ

個人利用なら localhost のみで十分です。VPS や LAN で公開するなら、デフォルトパスワードを変更し、強い JWT_SECRET と API_KEY_SECRET を設定し、Dashboard を公衆インターネットに直接出さず、/v1/* に Bearer API key を要求します。

docker run -d \
  --name 9router \
  -p 20128:20128 \
  --env-file ./.env \
  -v 9router-data:/app/data \
  -v 9router-usage:/root/.9router \
  9router

まとめ

9Router は AI コーディングツールのローカル gateway です。Claude Code、Codex、Cursor、Cline などを http://localhost:20128/v1 に集約し、モデル選択、形式変換、token 圧縮、quota 追跡、fallback を処理します。

複数 provider を使う重めの AI コーディングユーザーに向いています。まず 1 つのツールと 1 つの provider から試し、徐々に combo とアカウントを増やすのが無難です。

参考資料

Claude Code 24の使い方：計画モード、巻き戻し、CLAUDE.md、Skills、Agents、プラグイン

Fri, 08 May 2026 08:54:14 +0800

Claude Code は単なるチャット欄ではない。プロジェクトディレクトリに入り、ファイルを読み書きし、コマンドを実行し、コンテキストを維持できるコーディング Agent に近い。

要求を投げてコード生成を待つだけだと、計画が曖昧、権限確認が多い、コンテキストが長くなる、結果が気に入らない、戻し方が分からない、プロジェクトルールを残せない、といった問題にすぐ当たる。

ここでは、Claude Code を使い始める開発者向けに、よく使う操作を整理する。

まずプロジェクトディレクトリで起動する

Claude Code は、適当な場所で開くより、プロジェクトディレクトリ内で起動するほうがよい。

まずプロジェクト用フォルダを作り、その中でコマンドラインを開いて Claude Code を起動する。

claude

初回に現在のフォルダを信頼するか聞かれたら、確認してから進める。これで Claude Code は現在のプロジェクトを基準にファイルを読み、作成し、コマンドを実行できる。

練習には、写真家のポートフォリオサイトを作らせるようなタスクが向いている。見た目を確認でき、ファイル生成、コマンド実行、巻き戻し、リファクタリングを一通り試せる。

計画モードで方向を先に決める

Claude Code は複雑なタスクでは計画モードに入ることがある。計画モードでは、先に要件を話し合い、手順を分解してから、実行を承認する。

計画が出た後は、よく次のような選択肢が出る。

計画を承認し、以後の編集ツール使用も自動承認する。
計画を承認するが、以後の編集は手動確認する。
実行を止め、計画についてさらに Claude Code と話す。

タスクが明確なら承認して進める。まだ曖昧なら、ページの雰囲気、技術スタック、ディレクトリ構成、インタラクション、受け入れ条件をさらに詰める。

計画モードの利点は手戻りを減らすことだ。いきなり Agent に作業させると多くのファイルが作られるが、方向が間違っていると後で修正が荒れやすい。

Shift + Tab でモードを切り替える

Claude Code では Shift + Tab で作業モードを切り替えられる。よく使うのは、計画モードへの切り替えや、編集ツールの自動承認モードへの切り替えだ。

おすすめの使い分け：

新規プロジェクト、新機能、大きな変更：まず計画モード。
小さな修正、明確なバグ修正：直接実行。
削除、置換、依存関係のインストール：手動確認を残す。

計画モードでは、Claude Code がプロジェクト詳細を質問することがある。方向キーで選び、Enter で確定する。フィードバックを送ると、それに合わせて計画が更新される。

権限確認をすべて開放しない

Claude Code がコマンド実行、ファイル編集、プログラム起動を行うとき、権限を求めることがある。

よくある選択肢：

今回だけ許可。
現在の会話内で同種コマンドを許可。
拒否または一時停止。

ローカルページの起動、開発サーバーの実行、ファイル確認なら必要に応じて許可してよい。ただし、クリックを減らすために「すべて自動許可」で長く使うのは避ける。

完全自動の権限は、リスクが低く、内容を理解しており、Git バックアップがある場合だけに向く。日常利用では、削除、上書き、依存関係インストール、ネットワーク、コミット、スクリプト実行には人間の確認を残す。

ターミナルモードでローカルコマンドを実行する

Claude Code ではターミナルコマンドモードに入り、ローカルコマンドを実行できる。

ページ生成後、HTML ファイルを開く例：

`1`	`start index.html`

start は Windows でファイルを開くコマンドで、後ろにファイル名を付ける。エクスプローラーで探すより速い。

ターミナルモードに向く操作：

生成ページを開く。
ディレクトリを確認する。
開発サーバーを起動する。
テストやビルドを実行する。

一方、再帰削除、ディレクトリ移動、一括上書き、システム環境変更のような高リスク操作には注意する。

結果が違うときは早めに巻き戻す

Claude Code が作ったページやコードが期待と違い、修正するほど乱れていくなら、早めに巻き戻す。

巻き戻しでは、会話やコードを特定の時点へ戻せる。よくある選択肢：

コードと会話を同時に戻す。
会話だけ戻す。
コードだけ戻す。
以前の内容を要約に圧縮する。
キャンセルする。

明らかに方向がずれた場合は、コードと会話を同時に戻すのがおすすめだ。コンテキストとファイル状態を一緒にきれいな位置へ戻せる。

ただし、Claude Code の巻き戻しは通常、内蔵ツールで作成・変更したファイルが対象だ。外部コマンドで作ったファイルは完全には戻らないことがある。重要なプロジェクトでは Git と併用する。

長いプロンプトはエディタで書く

複雑な要件を1行の入力欄に詰め込まない。

長いプロンプトをテキストエディタで編集できる場合は、エディタで要件を書き、保存してから送る。

長いプロンプトには次を書くとよい。

目的。
使用する技術スタック。
してはいけないこと。
残すべきファイル。
完了後の確認方法。
ページや機能の受け入れ条件。

例えば普通の HTML ページを現代的な技術スタックへリファクタリングしたい場合、「リファクタリングして」だけでは足りない。コンポーネント化、見た目の維持、レスポンシブ対応、ビルド確認まで明記する。

終了後は履歴から会話を復元する

途中で Claude Code を終了する必要がある場合は、通常通り終了する。その後、同じプロジェクトディレクトリに戻って再起動する。

claude

以前の記録が直接出ない場合は、履歴関連コマンドで最近の会話を見て、以前の会話を読み込む。

これは中断後の継続に便利だ。ただし会話履歴だけを記憶として頼らない。プロジェクトルール、技術スタック、よく使うコマンド、注意点はプロジェクトファイルに書く。

CLAUDE.md にプロジェクトルールを保存する

CLAUDE.md は Claude Code にとって重要な記憶ファイルだ。通常はプロジェクトルートに置き、プロジェクトルール、技術スタック、ディレクトリ構造、協業上の制約を書く。

初期化は次で行える。

/init

CLAUDE.md に向いている内容：

プロジェクト目標。
技術スタック。
起動、テスト、ビルドのコマンド。
ディレクトリ説明。
コードスタイル。
禁止操作。
コミットとデプロイルール。

各会話で、Claude Code はこの種のルールをコンテキストの一部として利用できる。プロジェクト説明書と考えると分かりやすい。

簡単な検証方法は、CLAUDE.md に明確なルールを追加してから質問することだ。回答がそのルールに従えば、プロジェクト記憶を読んでいる。

@ でファイルを参照する

入力欄で @ を使うと、ファイルや Agent を選び、現在の会話コンテキストに追加できる。

向いている場面：

設定ファイルを読ませる。
特定ページを修正させる。
CLAUDE.md や他の文書に基づいて続けさせる。
「このファイルだけ見て、構造を推測しない」と明示する。

ファイル内容を入力欄に貼るより、@ 参照のほうが明確で漏れにくい。

コンテキストを確認・圧縮する

長時間会話すると、コンテキストは大きくなる。長すぎるとモデルが遅くなったり、初期の細部を無視し始めたりする。

現在の使用状況は次で確認できる。

`1`	`/context`

長くなったら履歴を圧縮する。

`1`	`/compact`

それでも効果が悪い場合は、現在のコンテキストを消す。

/clear

消した後も、Claude Code はプロジェクトファイル、CLAUDE.md、現在のディレクトリから一部を再理解できる。ただし完全な会話履歴は残らない。

実用的には、1つのタスクが終わったら新しい会話にし、プロジェクトルールは CLAUDE.md に書き、臨時の議論を1つのチャットに積み続けない。

Skills：固定フローを説明書にする

Skills は Claude Code の作業説明書と考えられる。一度きりのプロンプトではなく、再利用できるタスクフローだ。

例えば週報をよく作るなら、週報 Skill を作り、次を明記する。

必要な入力。
出力形式。
口調と構成。
必ず残す内容。
捏造してはいけない内容。

Skills は通常、name、description、具体的な指示で構成される。グローバル Skills ディレクトリに入れると、Claude Code は関連タスクで認識して読み込める。

向いている作業：

週報。
コードレビューのテンプレート。
文書整理。
画像の一括処理。
固定形式の記事。
プロジェクト初期化フロー。

同じプロンプトを何度もコピーしているなら、Skill 化を検討するとよい。

Agents：サブタスクを独立した助手へ渡す

Agents は Skills と違う。

Skill は説明書に近く、Claude Code にやり方を教える。Agent は独立した助手に近く、主会話の外で作業し、結果を返す。

Agents の価値はコンテキストの隔離だ。コード点検なら、読み取り専用 Agent を作り、プロジェクトを読むだけでレポートを出させる。ファイルを直接変更しないので、主会話を汚さず、誤操作も減らせる。

Agent 作成時に考えること：

プロジェクト級かユーザー級か。
Claude Code に設定を生成させるか。
どのツール権限を許すか。
どのモデルを使うか。
記憶を保存するか。
Agent のプロンプトが十分明確か。

コード点検 Agent には、まず読み取り権限だけを与えるのがおすすめだ。先にレポートを出させ、その後で主会話が修正するか判断する。

プラグイン：Skills、Agents、MCP、Hooks をまとめる

プラグインは、より完全な能力パッケージだ。中には次が含まれることがある。

Skills
Agents
MCP
Hooks

単体の Skill より、プラグインはまとまった能力に向いている。例えばフロントエンドデザイン用プラグインなら、見た目のルール、レイアウト、コンポーネント習慣、関連 Agent をまとめて持てる。

インストール時には、よく次の場所を選べる。

ユーザーディレクトリ：全プロジェクトで有効。
プロジェクトディレクトリ：プロジェクトと共有。
ローカルプロジェクトディレクトリ：現在の PC だけで有効。

個人で常用する能力はユーザーディレクトリ、チームの約束はプロジェクトディレクトリ、一時テストはローカルに置くとよい。

プラグインは特定タスクの品質を上げる

フロントエンドページ生成では、プラグインは素のプロンプトより安定しやすい。

同じ「写真家の個人サイトを作る」でも、普通のプロンプトだけなら見られるページができる程度かもしれない。フロントエンドデザインプラグインを明示すると、構造、視覚階層、余白、配色、完成度が良くなりやすい。

もちろんプラグインは人間の審美眼を置き換えない。より良い初稿を作らせ、人間が細部を調整するのが現実的だ。

より安定した Claude Code ワークフロー

これらを組み合わせると、安定した流れになる。

プロジェクトディレクトリで claude を起動する。
まず計画モードで要件を話す。
承認前に技術スタックと受け入れ条件を確認する。
高リスク操作は手動確認を残す。
ターミナルモードでプレビューとテストを行う。
方向がずれたら早めに巻き戻す。
プロジェクトルールを CLAUDE.md に書く。
長い会話では定期的にコンテキストを確認・圧縮する。
繰り返す作業は Skills にする。
点検、調査、分析は読み取り専用 Agents に渡す。
特定分野のタスクはプラグインを優先する。
重要プロジェクトでは常に Git のチェックポイントを作る。

こう使うほうが、「一文送って生成を待つ」よりはるかに安定する。

まとめ

Claude Code の効率はモデル能力だけでなく、ワークフロー制御からも生まれる。

計画モードは方向を決め、権限確認はリスクを抑え、巻き戻しは手戻りを減らす。CLAUDE.md はプロジェクトルールを保存し、/context、/compact、/clear はコンテキストを管理する。Skills は固定フローを再利用し、Agents は複雑なサブタスクを隔離し、プラグインはまとまった能力をプロジェクトへ持ち込む。

Claude Code をうまく使うには、明確な境界の中で継続的に作業させることが大事だ。プロジェクト全体を一度に丸投げするのではない。

opencode、Claude Code、Codex の違いとは？オープンソース AI コーディングツールガイド

Fri, 08 May 2026 08:33:37 +0800

opencode は anomalyco が公開しているオープンソースの AI Coding Agent だ。位置づけは明確で、開発者がターミナル内で、プログラム可能で拡張しやすく、複数のモデル提供元に接続できるコードアシスタントを使えるようにする。

Claude Code や Codex と並べて見ると、3つはいずれも同じ種類の問題を解こうとしている。AI を実際のコードベースに入れ、コンテキストを理解し、ファイルを変更し、コマンドやテストを実行できるようにすることだ。ただし、製品としての向きは異なる。

opencode はオープンソース、複数モデル対応、ターミナル TUI を重視する。Claude Code は Anthropic のモデルエコシステムとローカルでの開発協業を重視する。Codex は OpenAI の AI coding agent であり、ターミナル、IDE、Codex app、クラウドタスクから利用できる。

opencode が向いている人

opencode は次のような開発者に向いている。

ターミナル内でコード変更、プロジェクト分析、エンジニアリングタスクを進めたい人。
AI Coding Agent を単一のモデル提供元に縛られたくない人。
オープンソースツールを好み、自分で監査、拡張、二次開発したい人。
Neovim、TUI、コマンドラインワークフローに慣れている人。
将来的にデスクトップ、モバイル、その他のクライアントから同じコーディングエージェントをリモート操作したい人。

重要なのは、単なるチャットウィンドウを作ることではない。開発者が普段使っているターミナルとプロジェクトディレクトリの中に、AI コーディング能力を入れることだ。

インストール方法

公式 README には複数のインストール方法が用意されている。

# 直接インストール
curl -fsSL https://opencode.ai/install | bash

# npm
npm i -g opencode-ai@latest

# Windows
scoop install opencode
choco install opencode

# macOS と Linux
brew install anomalyco/tap/opencode
brew install opencode

# Arch Linux
sudo pacman -S opencode
paru -S opencode-bin

# その他
mise use -g opencode
nix run nixpkgs#opencode

公式 README では、古いバージョンの残存による問題を避けるため、インストール前に 0.1.x より前のバージョンを削除することも推奨している。

インストールスクリプトは次の優先順位でインストール先を選ぶ。

$OPENCODE_INSTALL_DIR
$XDG_BIN_DIR
$HOME/bin
$HOME/.opencode/bin

パスを指定したい場合は、次のように書ける。

1
2

OPENCODE_INSTALL_DIR=/usr/local/bin curl -fsSL https://opencode.ai/install | bash
XDG_BIN_DIR=$HOME/.local/bin curl -fsSL https://opencode.ai/install | bash

デスクトップアプリはまだ Beta

コマンドラインツールに加えて、opencode はデスクトップアプリも提供している。ただし現在は Beta 扱いだ。GitHub Releases または opencode.ai/download からダウンロードできる。

デスクトップ版は次のプラットフォームに対応している。

プラットフォーム	ファイル
macOS Apple Silicon	`opencode-desktop-mac-arm64.dmg`
macOS Intel	`opencode-desktop-mac-x64.dmg`
Windows	`opencode-desktop-windows-x64.exe`
Linux	`.deb`、`.rpm` または `.AppImage`

macOS と Windows では、パッケージマネージャーからデスクトップ版をインストールすることもできる。

# macOS
brew install --cask opencode-desktop

# Windows
scoop bucket add extras
scoop install extras/opencode-desktop

2つの内蔵 Agent モード

opencode には2つの内蔵 Agent があり、Tab キーで切り替えられる。

build はデフォルトモードで、完全な開発権限を持つ。コードを直接変更し、コマンドを実行し、エンジニアリングタスクを進める用途に向いている。

plan は読み取り専用モードだ。未知のコードベースを分析し、プロジェクト構造を理解し、変更方針を立てる用途に向いている。デフォルトではファイル編集を拒否し、bash コマンドを実行する前に確認する。

さらに、opencode には複雑な検索や多段階タスクのための general サブ Agent もある。ユーザーはメッセージ内で @general と入力して呼び出せる。

この設計は実用的だ。実際に手を動かす前に plan でプロジェクトを把握し、コードを変更する必要が出たら build に切り替える。大規模リポジトリでは、読み取り権限と書き込み権限を分けることで誤操作を減らせる。

Codex とは

Codex は OpenAI の AI coding agent で、開発者がコードを書き、コードレビューを行い、bug を修正し、エンジニアリングタスクを出荷するのを支援する。

単なるコード補完ツールとは異なり、Codex はコードベースを操作できる Agent に近い。ローカルツール内で開発者とペアになって作業することも、クラウドにタスクを委任することもできる。OpenAI の公式資料では、Codex は CLI、IDE、Codex app、ChatGPT/Codex クラウドなど複数の入口から利用できると説明されている。

開発者にとって、Codex のポイントは次の通りだ。

コードベースを読み、ファイルを編集し、コマンドとテストを実行できる。
ターミナル、IDE、アプリ、クラウドなど複数のインターフェースに対応する。
bug 修正、機能開発、リファクタリング、移行、コードレビュー、テスト補完に向いている。
OpenAI アカウント、モデル、Codex 製品体系との結びつきが強い。
クラウドタスクは、比較的明確な複数のエンジニアリングタスクを並行処理するのに向いている。

opencode が開かれたターミナルエージェントフレームワークに近いとすれば、Codex は OpenAI が提供する一式の AI コーディングワークベンチに近い。ローカルでペア作業でき、クラウドに委任でき、チームはそれをより長いエンジニアリングフローへ組み込める。

3つの主な違い

opencode、Claude Code、Codex はいずれも AI コーディングツールだが、選ぶときはまず次の観点を見るとよい。

ツール	中心的な位置づけ	主な強み	向いている用途
`opencode`	オープンソース AI Coding Agent	オープンソース、複数モデル、TUI、クライアント/サーバー構成	開かれたツールチェーン、交換可能なモデル、ターミナル中心のワークフローを求める開発者
`Claude Code`	Anthropic のコマンドライン型コーディングツール	Claude モデル体験、コード理解、長いコンテキスト、エンジニアリングタスク協業	Claude/Anthropic エコシステムを使っていて、ローカルでコードタスクを進めたい開発者
`Codex`	OpenAI の AI coding agent	CLI、IDE、Codex app、クラウドタスク、複数 Agent ワークフロー	ChatGPT/OpenAI を使っていて、ローカルでのペア作業とクラウド委任を併用したいチーム

簡単に言えば、opencode のキーワードは「オープン」と「交換可能」、Claude Code のキーワードは「Claude エコシステム」と「ローカル開発エージェント」、Codex のキーワードは「OpenAI エコシステム」と「複数入口の協業」だ。

Claude Code との違い

opencode の公式 FAQ は Claude Code と直接比較している。両者の能力はかなり近いが、主な違いは次の通りだ。

第一に、opencode は 100% オープンソースプロジェクトで、コードは GitHub にホストされ、MIT license で提供されている。

第二に、opencode は単一のモデル提供元に縛られない。OpenCode Zen が提供するモデルを推奨しているが、Claude、OpenAI、Google、またはローカルモデルとも組み合わせられる。開発者にとっては、モデルのコスト、能力、可用性が変わっても、特定のプラットフォームにロックインされにくいという意味がある。

第三に、opencode は任意の LSP サポートを内蔵している。コード補完、ジャンプ、診断、プロジェクト理解にとって、LSP は非常に重要な基盤だ。

第四に、opencode は TUI を重視している。Neovim ユーザーと terminal.shop の作成者によって作られており、製品の重心は明らかにターミナル体験にある。

第五に、opencode はクライアント/サーバー構成を採用している。つまり、opencode を自分のコンピューター上で動かし、将来的に TUI、デスクトップ、モバイル、その他のクライアントから制御できる。TUI はそのうちの一つのフロントエンドにすぎない。

opencode、Claude Code、Codex をいつ選ぶか

すでに Claude Code や Codex を使っている場合、opencode がすぐにそれらを置き換える必要はない。より自然な見方は、opencode がオープンで、モデルを交換でき、ターミナル寄りの選択肢を提供しているというものだ。

opencode を優先して検討したい場面は次の通り。

AI コーディングツールをできるだけオープンソースにしたい。
ワークフローを特定のモデル提供元に縛られたくない。
同じツールで Claude、OpenAI、Google、またはローカルモデルを試したい。
TUI が好きで、主要な作業フローをデスクトップアプリやWebアプリに中断されたくない。
クライアント/サーバー構成によるリモート制御能力に関心がある。

Claude Code を優先して検討したい場面は次の通り。

主に Claude モデルを使っている。
長いコンテキスト、コード理解、複雑なエンジニアリングタスク協業を重視している。
ローカルリポジトリ内で変更、テスト、リファクタリングを継続的に進めたい。
Anthropic による Claude Code のデフォルト製品体験を信頼している。

Codex を優先して検討したい場面は次の通り。

すでに ChatGPT または OpenAI アカウント体系を使っている。
同じ coding agent をターミナル、IDE、デスクトップアプリ、クラウドタスクで使いたい。
明確な bug 修正、機能開発、移行、テスト補完をクラウドに委任して並行処理したい。
コードレビュー、バックグラウンドタスク、チーム協業、複数 Agent ワークフローが必要だ。

公式の一体化された体験、デフォルトのモデル設定、企業管理、既製の統合を重視するなら、Claude Code や Codex のほうが楽な場合がある。制御性、オープン性、provider-agnostic を重視するなら、opencode は注目に値する。

注意点

opencode、Claude Code、Codex はいずれも変化が速い。GitHub release、インストールコマンド、デスクトップ版のファイル名、モデルの可用性、プラン権限は変わる可能性がある。インストールや選定の前には、それぞれの公式 README、ドキュメント、リリースページを直接確認するのがよい。

また、opencode のデスクトップアプリはまだ Beta と表示されており、安定した本番用ツールとして最初から扱うべきではない。日常的なエンジニアリングタスクでは、ターミナル版が引き続き主な入口になる。

ツールの流れとして見ると、opencode は AI Coding Agent のオープンツールチェーン方向を代表している。モデルを交換でき、クライアントも交換でき、コアの代理能力をできるだけ開く方向だ。一方、Codex と Claude Code は、モデル企業が coding agent を完成度の高い製品入口として作る方向に近い。開発者にとって、この2つの流れは長く併存するだろう。

参考リンク

opencode GitHub：https://github.com/anomalyco/opencode
opencode 公式サイト：https://opencode.ai
opencode ドキュメント：https://opencode.ai/docs
opencode Releases：https://github.com/anomalyco/opencode/releases
OpenAI Codex：https://openai.com/codex/
Using Codex with your ChatGPT plan：https://help.openai.com/en/articles/11369540-codex-in-chatgpt
OpenAI Codex CLI Getting Started：https://help.openai.com/en/articles/11096431-openai-codex-ci-getting-started

Claude Opus 4.7、Sonnet 4.6、Haiku 4.5 の違いとは？Claude モデル選びガイド

Fri, 08 May 2026 08:19:03 +0800

Anthropic の中核的な大規模モデルは、主に Claude シリーズとして進化している。2026 年 5 月時点で、Claude の主流プロダクトラインは 4.x 世代に入り、全体としては今も三つの階層に分かれている。Opus は最高性能、Sonnet は性能とコストのバランス、Haiku は速度と費用対効果を担う。

素早く選びたいだけなら、まずは次の一文を覚えておくとよい。

最も複雑で重い推論や agentic coding：まず Claude Opus 4.7 を検討する。
多くの開発、執筆、分析、企業 API の場面：Claude Sonnet 4.6 から始めるのが安定している。
高並行、低遅延、コスト重視のタスク：Claude Haiku 4.5 を検討する。

現在の主流モデル

Anthropic の公式モデルドキュメントをもとにすると、現在の Claude の主流モデルは次のように理解できる。

モデル	位置づけ	適した用途
`Claude Opus 4.7`	現在最も強力な汎用利用可能モデルで、複雑な推論と agentic coding 向け	大規模コードベースのリファクタリング、多段階タスク、複雑な戦略分析、より高い一貫性が必要な作業
`Claude Sonnet 4.6`	速度、能力、コストのバランスがよく、100 万 token のコンテキストウィンドウに対応	コード生成、長文書分析、企業ナレッジワーク、Agent 開発、日常的な高品質の生産タスク
`Claude Haiku 4.5`	最も高速で低コストな小型モデルの階層だが、フロンティアモデルに近い能力も持つ	リアルタイム対話、カスタマーサポート、バッチ分類、簡単なコード支援、高並行 API 呼び出し

ここでは、二つの命名上の注意点がある。

第一に、公式名称は Claude Haiku 4.5 であり、Claude 4.5 Haiku ではない。第二に、Claude Mythos Preview は一般ユーザーや開発者向けの主流利用可能モデルではない。これは Project Glasswing に関連する管理された研究プレビューであり、主に防御的なサイバーセキュリティワークフロー向けなので、通常の Claude モデル選びに混ぜるべきではない。

Opus：最も難しい問題を扱う

Opus は Anthropic が最強モデルに使う階層だ。Claude Opus 4.7 の重点は、安さでも最速であることでもない。複雑で、多段階で、何度も検証が必要なタスクにより向いている点にある。

次のような場面により適している。

多数のファイルにまたがる大規模なコード変更。
複雑なシステムリファクタリングとアーキテクチャ推論。
長い処理連鎖を持つ Agent タスク。
より強い視覚理解、文書理解、多段階計画が必要な作業。
ミスのコストが高い企業分析タスク。

一度失敗したときの代償が大きいタスクや、作業を始める前にモデルへより深く文脈を理解してほしい場合、Opus は試す価値が高いことが多い。

Sonnet：多くの人にとってのデフォルト起点

Claude Sonnet 4.6 は、デフォルトの入口としてより使いやすいモデルだ。その位置づけは「低スペック版 Opus」ではなく、十分に強い推論、プログラミング、視覚理解、長いコンテキスト、agent planning を、より管理しやすいコストと速度の中に収めることにある。

開発者にとって、Sonnet 4.6 の価値は主に三つある。

非常に長いコンテキストを扱えるため、コードベース、契約書、レポート、複数の資料を入れやすい。
Claude Code、API、企業利用の場面で常用モデルとして使いやすい。
Opus よりコストが低く、高頻度利用に向いている。

どの Claude モデルから始めればよいかわからない場合は、通常 Claude Sonnet 4.6 から始めればよい。タスクが明らかにより強い能力を必要とするときだけ、Opus に切り替える。

Haiku：速さと安さがより重要なとき

Claude Haiku 4.5 は小型モデルの階層だが、単純に「弱いモデル」と考えるべきではない。Anthropic はこれを高速かつ低コストでありながら、フロンティアモデルに近い能力を保持するモデルとして位置づけている。

次のような場面に適している。

リアルタイムチャットとカスタマーサポートボット。
大量の短文分類。
低遅延 API 呼び出し。
簡単なコード修正と高速プロトタイピング。
複数 Agent ワークフロー内のサブタスク実行。

タスク自体が明確で、文脈が複雑ではなく、スループットが重要な場合、Haiku は大きなモデルを盲目的に使うより合理的なことが多い。

Claude のツール能力

Claude シリーズは単なるチャットモデルではない。Anthropic は現在、モデル能力を複数のプロダクトや開発者ツールに組み込んでいる。

Claude Code は開発者向けのコマンドライン型プログラミングツールで、コードベースの読み取り、ファイル編集、コマンド実行、テスト実行ができる。継続的にエンジニアリングタスクを進める用途に向いている。その体験は、モデル自体のコード理解、コンテキスト管理、ツール呼び出しの安定性に大きく依存する。

Computer Use は、スクリーンショット、マウス、キーボードを通じてモデルにデスクトップ環境を操作させる能力だ。慎重な利用が必要であり、公式ドキュメントでも誤操作やセキュリティリスクを避けるため、隔離環境で実行することが強調されている。

Artifacts は Claude アプリ側の体験に近く、コード、ページプロトタイプ、グラフ、文書の結果をインターフェース上でプレビューし、反復できるようにするものだ。これは単独のモデルではなく、Claude のプロダクト形態の一部である。

「Managed Agents」や「自己進化 Agent」のような表現については、記事を書く際に慎重であるべきだ。Anthropic が Agent SDK、Claude Code、長いコンテキスト、ツール呼び出し、企業ワークフローを強化しているのは確かだが、すでに制御不能な自己進化能力を持つかのように説明すべきではない。

アクセス方法

一般ユーザーは Claude.ai のWeb版またはモバイルアプリから Claude を利用できる。利用できるモデル、上限、機能はプランによって変わる。

開発者には通常、いくつかの接続方法がある。

Anthropic Console と Claude API。
Amazon Bedrock。
Google Cloud Vertex AI。
Microsoft Foundry。

利用可能なモデル、コンテキストウィンドウ、価格、地域サポートは変化する可能性がある。開発前には、Anthropic の公式モデルドキュメントと各クラウドプラットフォームのページを確認するのがよい。

どう選ぶか

実際に使うとき、最初から最強モデルを追いかける必要はない。よりよい方法は、タスクのコストに応じて階層化して選ぶことだ。

日常的な執筆、コード生成、長文書分析、知識整理、多くの Agent プロトタイプであれば、まず Claude Sonnet 4.6 を使う。通常、費用対効果と汎用能力の最良の出発点になる。

より強い複雑推論、ファイル横断のエンジニアリング変更、長い処理連鎖の計画、またはより高い信頼性が必要な場合は、Claude Opus 4.7 に切り替える。

分類、要約、カスタマーサポート、バッチ処理のように、タスクが簡単で量が多く、遅延に敏感な場合は、Claude Haiku 4.5 を候補に入れる。

Claude のモデルラインは、単なる「新バージョンが旧バージョンを置き換える」ものではない。タスクの難度、速度、コストに応じて階層化されたツールボックスだ。最も高価なモデルを盲目的に使うより、適切なモデルを選ぶことのほうが重要である。

参考リンク

Anthropic Models Overview：https://platform.claude.com/docs/en/about-claude/models/overview
Introducing Claude Opus 4.7：https://www.anthropic.com/news/claude-opus-4-7
Introducing Claude Sonnet 4.6：https://www.anthropic.com/news/claude-sonnet-4-6
Introducing Claude Haiku 4.5：https://www.anthropic.com/news/claude-haiku-4-5
Anthropic Computer Use Tool：https://docs.anthropic.com/en/docs/build-with-claude/computer-use

ChatGPT、Claude Code、Gemini の記憶機構は何が違うのか

Thu, 07 May 2026 14:47:17 +0800

AI 製品における「記憶」はますます重要になっている。これは AI が「単発の会話ツール」から「長期的な協力相手」へ移行していることを示している。毎回背景を説明し直す必要がなくなり、好みを繰り返し伝える必要もなく、同じプロジェクトを何度も理解させる必要も減る。

しかし、製品ごとの記憶は同じものではない。ChatGPT、Claude Code、Gemini はいずれも「AI がより長く覚える」問題を扱っているが、設計目標、保存場所、透明性、適用シーンは大きく異なる。

2026 年 5 月 7 日時点では、おおまかに3つに分けられる。

ChatGPT は「個人アシスタントの記憶」に近い。
Claude Code は「エンジニアリングプロジェクトの記憶」に近い。
Gemini は「Google エコシステムの文脈」に近い。

ChatGPT：人を中心にした長期的な好み

ChatGPT の記憶機構は主に個人協作向けだ。関心の中心は「あなたは誰か」「何を好むか」「長期的に何をしているか」にある。

OpenAI は現在、ChatGPT の記憶を saved memories と chat history に分けている。

saved memories は、ChatGPT が保存する重要情報だ。名前、好み、目標、よく使う技術スタック、文章の癖などが含まれる。ユーザーが明示的に覚えるよう頼むこともできるし、ChatGPT が会話の中から将来役立つと判断した情報を保存する場合もある。

chat history は、回答時に過去の会話を参照する仕組みだ。すべての会話がそのまま記憶になるわけではなく、必要に応じて過去の会話から関連文脈を探す。

つまり ChatGPT の中核ロジックは、同じユーザーを会話をまたいで理解することだ。

典型例は次のようなものだ。

「今後コード例はできるだけ簡潔にして。」
「私は主に Python と TypeScript を使っている。」
「AI ツールについての Hugo ブログを書いている。」
「先に結論を見て、その後に詳細を読むのが好き。」

これらの記憶は特定プロジェクトに紐づくものではなく、アカウントと個人の利用習慣についてくる。

Memory Sources：個人化の出所を見えるようにする

OpenAI は 2026 年 5 月の更新で Memory sources を強調した。

これは新しい記憶タイプではなく、ChatGPT が回答を個人化するときに参照した情報源をユーザーに見せる仕組みだ。OpenAI のヘルプ文書によると、Memory Sources には次のようなものが表示される場合がある。

過去のチャット。
保存された記憶。
カスタム指示。
ファイルライブラリ内のファイル。
接続済み Gmail のメール。

ファイルや Gmail の表示範囲は、プラン、地域、接続状態によって制限される。OpenAI はまた、Memory sources が回答に影響したすべての要因を表示するとは限らず、個人化の理解と管理を助けるものだと説明している。

これは重要だ。AI が「あなたを覚える」ほど、ユーザーは何に基づいて回答したのかを知る必要がある。そうでなければ個人化はブラックボックスになりやすい。AI が自分を知っているように見えるが、なぜ知っているのか分からない状態になる。

ChatGPT の強みは、会話やテーマをまたいで個人の好みを継続的に理解することだ。一方で、記憶が古くなったり、古い記憶がまだ回答に影響していることをユーザーが忘れたりするリスクもある。そのため saved memories と古いチャットは定期的に整理したほうがよい。

Claude Code：コードベースとエンジニアリングルールを中心に

Claude Code の記憶機構はエンジニアリング協作寄りだ。関心の中心は「ユーザーが普段何を好むか」ではなく、「このコードベースをどう変更すべきか」だ。

Claude Code には混同されやすい2種類の記憶がある。

明示的なプロジェクト記憶：CLAUDE.md。
自動プロジェクト記憶：Auto Memory。

CLAUDE.md は最も基本的で安定したプロジェクト記憶ファイルだ。プロジェクトルートにも、サブディレクトリにも置ける。Claude Code はこれらのファイルを読み、プロジェクト説明と作業ルールとして扱う。

CLAUDE.md に書くのに適した内容は次の通りだ。

よく使う build、test、lint コマンド。
コードスタイルと命名規則。
プロジェクトアーキテクチャ。
モジュール境界と危険な領域。
チームの約束事とコミットフロー。

CLAUDE.md をリポジトリに置けば、Git にコミットしてチーム共有の agent 説明書にできる。これは ChatGPT のクラウド上の個人記憶とはまったく異なる。

Claude Code Auto Memory：プロジェクト経験を自動で蓄積する

Claude Code には現在 Auto Memory もある。目的は、ユーザーが毎回手で説明を書かなくても、Claude が複数セッションにまたがってプロジェクト経験を自動的に蓄積できるようにすることだ。

Claude Code の文書によると、Auto Memory は作業中に Claude が自分用のメモを保存する仕組みだ。build コマンド、デバッグで分かったこと、アーキテクチャ説明、コードスタイルの好み、ワークフロー習慣などが対象になる。すべてのセッションで保存するわけではなく、将来役立ちそうな情報を判断する。

誤解されやすい点がある。Auto Memory はデフォルトでプロジェクトルートの .claude/memory.md に書くわけではない。公式文書では、各プロジェクトはユーザーディレクトリ配下に独自の memory ディレクトリを持つと説明されている。パスは次のような形だ。

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

MEMORY.md は各会話開始時に最初の 200 行または 25KB が読み込まれ、詳細は別のトピックファイルへ分割される場合がある。Auto Memory ファイルはローカルの Markdown ファイルで、ユーザーは /memory から表示、編集、削除できる。

これにより Claude Code の記憶は「ローカル上のプロジェクト経験庫」に近くなる。ChatGPT の個人記憶よりコードベースに近く、単なる CLAUDE.md より動的だ。

ただし Auto Memory はローカルマシン上のものだ。リポジトリと一緒に他のマシンやクラウド環境へ自然に同期されるわけではない。チームで共有すべき安定したルールは、やはりプロジェクト内の CLAUDE.md に書くべきだ。

Gemini：Google エコシステムの文脈を中心に

Gemini の記憶ロジックはまた別だ。

Gemini にも保存情報と過去チャット参照の能力がある。Google のヘルプ文書では、ユーザーは生活、仕事、好みに関する情報を保存でき、Gemini は回答前に過去のチャットを参照できると説明されている。これらの情報を使うと、回答下部のソース領域に Your saved info や Previous chats が表示される場合がある。

しかし Gemini の差別化は「好みを数個保存する」ことだけではなく、Google エコシステム連携にある。

ユーザーが許可し、機能が利用可能な場合、Gemini は Gmail、Google Drive、Docs、Sheets など接続された Google アプリから文脈を取得できる。強みは、ユーザーが一つずつ教え込むことではなく、すでに Google アカウント内にある資料を検索可能な作業文脈にできることだ。

典型的な違いは次のようになる。

ChatGPT は「最近 LTO テープドライブを修理している」と覚える。
Gemini は Gmail から購入確認メールを見つけたり、Drive から修理メモを読んだりできる場合がある。

もちろん、Gemini が無条件で Google データすべてを読めるわけではない。アカウント種別、地域、権限、接続アプリ、Keep Activity 設定、具体的な製品提供状況に依存する。企業や学校アカウントでは、Google Workspace 管理者の制御も受ける。

より正確に言えば、Gemini の記憶は単純な「メモ帳」ではなく、「保存情報 + 過去チャット + Google エコシステム接続」の組み合わせだ。

3者の主な違い

次元	ChatGPT	Claude Code	Gemini
中心対象	人と好み	プロジェクトとコードベース	Google アカウントとエコシステム資料
典型的な記憶	好み、背景、長期目標	アーキテクチャ、コマンド、規約、デバッグ経験	saved info、過去チャット、Gmail/Drive/Docs 文脈
保存形態	OpenAI アカウント内の記憶とチャット文脈	`CLAUDE.md`、`MEMORY.md`、ローカル Markdown ファイル	Google アカウント活動、保存情報、接続アプリデータ
透明性	Memory sources で一部の出所が見える	Markdown ファイルを直接表示・編集できる	ソース表示、Gemini Apps Activity、Google 設定で管理
プロジェクト横断	強い。ユーザーアカウントに追従	弱い。主にプロジェクトまたはローカル project memory に追従	強い。Google 資料と権限に依存
チーム共有	直接共有には不向き	`CLAUDE.md` を Git で共有可能	主に Workspace と権限体系に依存
得意領域	個人の好みと長期アシスタント	長期コードプロジェクトと agent 協作	Google Workspace 資料検索とクロスツール作業

どう選び、どう使うか

AI に「自分は誰か、どんなスタイルが好きか、普段どう働くか」を覚えさせたいなら、ChatGPT の記憶が向いている。

文章スタイル、よく使う技術スタック、回答形式、職業背景、長期プロジェクトの方向といった個人の好みを保存するのに適している。重点は自己紹介コストを下げ、新しい会話を素早く始めることだ。

AI に「このコードベースをどう変えるか、どのコマンドが動くか、どの罠を避けるか」を覚えさせたいなら、Claude Code が向いている。

安定したルールは CLAUDE.md に書いてチーム共有する。動的な経験は Auto Memory に補助させる。重要な意思決定はローカル自動記憶にだけ残さず、文書や CLAUDE.md に整理するのがよい。

資料の多くが Gmail、Drive、Docs、Sheets にあるなら、Gemini のエコシステム文脈が有利だ。

過去メールの検索、Google Drive 文書の整理、カレンダーやオフィス資料との連携に向いている。Gemini を使うポイントは、チャット内で何度も思い出させることではなく、関連アプリの接続、権限、アクティビティ設定を正しくしておくことだ。

実用的な分担

3者は次のように分担できる。

ChatGPT は「自分の一般的な好み」を覚える。
Claude Code は「このリポジトリのエンジニアリング知識」を覚える。
Gemini は「Google エコシステム内の資料」を検索する。

つまり、ChatGPT は個人秘書、Claude Code はプロジェクト内のシニアエンジニア、Gemini は Google アカウント内の資料インデクサーに近い。

この3種類の記憶に絶対的な優劣はない。目的が違うだけだ。

最も注意すべきなのは混同することだ。個人の好みは必ずしもプロジェクト記憶に書くべきではない。プロジェクトアーキテクチャは必ずしもクラウド上の個人記憶に保存すべきではない。Google エコシステム検索は、モデルがあなたを長期的に本当に理解したことと同じではない。

短い判断

AI 記憶の次の段階は、単に「多く覚える」ことではない。記憶は階層化され、見えるようになり、制御可能である必要がある。

ChatGPT の重点は会話をまたいだ個人化、Claude Code の重点はコードプロジェクトの継続性、Gemini の重点は Google エコシステム文脈だ。本当に使いやすい長期 AI 協作は、すべての情報を一つのブラックボックスに詰め込むのではなく、異なる種類の記憶を適切な場所に置く。

個人の好みは個人記憶に、エンジニアリングルールはコードベースに、過去資料は元の文書やメールシステムに置く。AI がすべきことは、必要なときに正確にそれらの文脈を呼び出すことであり、すべてを一つに混ぜることではない。

Anthropic、Claude の利用上限を引き上げ、SpaceX と計算資源を拡大

Thu, 07 May 2026 14:26:14 +0800

Anthropic は 2026 年 5 月 6 日、Claude Code と Claude API の一部利用上限を引き上げると発表し、同時に SpaceX との新たな計算資源パートナーシップを明らかにした。

表面的には「利用枠が増える」という話だ。しかし本当に見るべき点は、モデル企業がプロダクト体験、サブスクリプション、API rate limits、インフラ供給を一体で設計し始めていることにある。ヘビーユーザーにとって、計算資源は抽象的な概念ではない。Claude Code のタスクをどれだけ回せるか、待ち時間を減らせるか、Opus モデルを安定して呼び出せるかに直結する。

Claude Code と API の上限はどう変わるか

Anthropic は今回、3つの変更を発表した。いずれも発表当日から有効だとしている。

第一に、Pro、Max、Team、席単位課金の Enterprise プラン向けに、Claude Code の5時間あたりの利用上限を2倍にする。

これは Claude Code のヘビーユーザーにとって分かりやすい変更だ。短時間に Claude Code でコードを読ませ、修正し、タスクを実行し続けると、これまでは5時間上限に達しやすかった。上限が2倍になれば、同じ作業時間の中でより多くの継続的な開発タスクをこなせる。

第二に、Pro と Max アカウントでは、Claude Code のピーク時間帯における上限引き下げがなくなる。

これは数字以上に重要だ。多くの AI ツールで体験を左右するのは、平常時の上限ではなく、混雑時に急に遅くなったり、使える量が減ったり、不安定になったりすることだ。ピーク時間帯の制限引き下げをなくすということは、Anthropic が有料ユーザーに対して混雑時でも予測しやすい体験を提供したいという意思表示でもある。

第三に、Claude Opus モデルの API rate limits を大きく引き上げる。原文では詳細な数値が画像の表で示されているが、要点は Opus API の呼び出し上限が明確に引き上げられたことだ。

開発者から見ると、Opus はより高価で重く、能力も高いモデルだ。Opus API の上限引き上げは、Anthropic が Claude をチャット画面で使わせるだけでなく、企業や開発者に Opus を実際の業務フローへ組み込んでほしいと考えていることを示している。

SpaceX との計算資源提携の重み

上限引き上げの背後には、新しい計算資源の供給がある。

Anthropic は、SpaceX の Colossus 1 データセンターの全計算容量を利用する契約を結んだとしている。この提携により、1か月以内に 300 メガワット超の新規容量、22万基超の NVIDIA GPU に相当するリソースを利用できるようになる。

この数字は2つのことを示している。

第一に、フロンティアモデル企業にとって、計算資源は依然としてボトルネックだ。モデル能力、コンテキスト長、ツール呼び出し、コーディングエージェント、マルチモーダル、企業用途はいずれも大量の推論リソースを消費する。ユーザーが増え、タスクが複雑になるほど、プラットフォームには安定した大規模 GPU 供給が必要になる。

第二に、AI インフラ競争は超大規模フェーズに入っている。以前はモデルランキング、機能、価格への注目が大きかった。今は電力、データセンター、ネットワーク、GPU をどれだけ早く確保できるかが、モデル能力を安定したプロダクトへ変えるうえで重要になっている。

Anthropic はまた、今回の SpaceX との提携が Claude Pro と Claude Max 加入者の容量体験を直接改善すると述べている。つまり、これは訓練用クラスタだけではなく、ユーザー向け推論にも関わる供給だ。

Anthropic の計算資源マップ

SpaceX は Anthropic にとって唯一の計算資源パートナーではない。

発表では、すでに公表されている複数のインフラ計画にも触れている。

Amazon との最大 5GW の契約。2026 年末までに約 1GW の新規容量を含む。
Google と Broadcom との 5GW 契約。2027 年から順次稼働予定。
Microsoft と NVIDIA との戦略的提携。300億ドル分の Azure 容量を含む。
Fluidstack と進める、米国 AI インフラへの 500億ドル投資。

共通しているのは、Anthropic が単一のハードウェアや単一のクラウドに自社を縛っていないことだ。原文でも、Claude の訓練と実行には AWS Trainium、Google TPU、NVIDIA GPU を使うと明記されている。

このマルチサプライヤー戦略には現実的な意味がある。1社のクラウドだけで、フロンティアモデルの訓練と大規模推論のピーク需要を長期的に満たすのは難しい。複数プラットフォームにまたがる構成はエンジニアリングの複雑さを増すが、サプライチェーンと容量のリスクを下げられる。

利用上限の引き上げは本質的に計算資源の問題

AI プロダクトの「上限」は、通常のインターネットサービスにおける会員特典の文言ではない。背後には実際のコストがある。

Claude Code がリポジトリを読み、パッチを生成し、長いタスクを実行するたびに、推論リソースが消費される。API ユーザーが Opus をサポート、金融分析、コードレビュー、文書処理、agent ワークフローに組み込めば、継続的な呼び出しが発生する。プラットフォーム側から見ると、上限を緩めるには、それを支える安定した計算資源が必要だ。

だから今回の発表の論理は明快だ。まずユーザーがより高い上限を得られることを説明し、次にそれがなぜ可能になったのかを説明している。SpaceX の新容量に加え、Amazon、Google、Microsoft、NVIDIA、Fluidstack との既存の協力は、より重い利用シーンを支えるためのものだ。

これが、AI プロダクトがプラン分けを強調する理由でもある。無料、Pro、Max、Team、Enterprise のユーザーは、計算資源の消費量も支払い能力も異なる。モデル企業は、上限、優先度、モデルアクセス、インフラコストを再調整しなければならない。

軌道上 AI 計算資源というシグナル

発表には未来的な細部もある。Anthropic は、この契約の一環として、SpaceX と複数ギガワット規模の軌道上 AI 計算資源を開発することにも関心を示したと述べている。

これは軌道上データセンターがすぐに現実の製品になるという意味ではない。より慎重に読むなら、フロンティア AI 企業が将来の計算資源供給を地上データセンターの外にも想像し始めている、ということだ。

AI データセンターは、電力、土地、冷却、ネットワーク、規制に制約される。訓練と推論の需要が増え続けるなか、業界はより多様なインフラ形態を模索するだろう。軌道上計算資源はいまは遠い話に聞こえるが、Anthropic の公式発表に登場したこと自体が、計算資源競争の想像力が広がっているというシグナルだ。

国際展開とコンプライアンス需要

Anthropic は、企業顧客、特に金融、医療、政府など規制産業の顧客が、コンプライアンスとデータレジデンシーのために地域内インフラをますます必要としているとも述べている。

これは、モデル企業が米国だけにデータセンターを集中させられないことを意味する。企業 AI が実業務に入るには、地域ごとの規制、データレジデンシー、サプライチェーン安全保障、電力コスト、地域社会との関係を扱わなければならない。Anthropic は、Amazon との協力にはアジアと欧州での追加推論能力が含まれるとしている。

また、大規模投資を支えられる法制度と規制枠組み、そして安全なサプライチェーンを備えた民主主義国を重視し、米国のデータセンターに関する電気料金コミットメントを他の法域へ広げる方法も検討しているという。

ここから分かるのは、AI インフラが単なる技術問題ではなく、エネルギー、製造業、地政学的経済の問題にもなっているということだ。

短い判断

Anthropic の今回の発表は、こう要約できる。Claude の利用上限を引き上げられるのは、背後に新しい大規模計算資源があるからだ。

ユーザーにとって短期的な影響は、Claude Code の5時間上限引き上げ、Pro と Max のピーク時制限減少、Opus API の呼び出し余地拡大だ。業界にとってより重要なのは、モデル企業の競争が「どのモデルが強いか」から「十分で安定し、コンプライアンスにも対応できる計算資源を継続的に確保できるか」へ広がっていることだ。

将来の AI プロダクト体験の差は、モデルパラメータやプロダクト設計だけでなく、インフラ能力からも生まれる可能性が高い。電力、GPU、データセンター、クラウド提携、地域コンプライアンスを組織できる企業ほど、フロンティアモデルを長期的に使えるサービスへ変えやすくなる。

CC Switch：Claude Code、Codex、Gemini CLI、OpenClawを一元管理するデスクトップツール

Wed, 06 May 2026 09:03:08 +0800

CC Switch は、AIコーディングを日常的に深く使うユーザー向けのデスクトップ管理ツールだ。解決しようとしている問題ははっきりしている。いま多くの人が Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw を同時に使っているが、それぞれ設定形式、Providerの書き方、MCP設定、Skills管理の方法が違う。

1つのツールだけを使うなら、手作業で設定を変えるのもまだ我慢できる。しかし複数のツールを混在させ、そこに公式アカウント、サードパーティAPI、リレーサービス、ローカルモデル、チーム共有設定まで加わると、JSON、TOML、.env を手で編集する作業はすぐに面倒になる。

CC Switch の位置づけは、こうした分散した設定を1つのクロスプラットフォームなデスクトップアプリに集約することだ。

何を解決するのか

現代のAIコーディングツールは、「コマンドラインの中にいる開発仲間」のようになりつつある。ただし、各ツールのエコシステムはまだ完全には統一されていない。

よくある課題は次の通りだ。

Claude Code、Codex、Gemini CLI、OpenCode、OpenClawで設定形式が異なる。
API Providerを切り替えるたびに、設定ファイルを何度も変更する必要がある。
MCP serverを複数ツールで重複して設定しがちになる。
CLAUDE.md、AGENTS.md、GEMINI.md のようなプロンプトファイルを統一して保守しにくい。
Skillsのインストール、同期、バックアップ、削除に集中管理の入口がない。
複数アカウント、複数relay、複数モデルサービスの切り替えが混乱しやすい。
設定ファイルを手作業で壊した場合、原因調査のコストが高い。

CC Switch の考え方は、ユーザーに各ツールの設定細部を覚えさせるのではなく、Provider、MCP、Prompts、Skills、Sessions、プロキシを1つの統一画面で管理するというものだ。

対応ツール

READMEに挙げられている主な対応対象は5種類ある。

Claude Code
Codex
Gemini CLI
OpenCode
OpenClaw

これらのツールは、AIコーディング、Agentワークフロー、コマンドライン上の協働という点で近い位置づけにある。ただし設定体系は異なっており、CC Switch の価値はその違いを包み込むところにある。

複数のAIコーディングツールをよく比較する人にとっては、毎回設定ファイルを手で開くよりかなり楽になる。

Provider管理

CC Switch の第一の機能はProvider管理だ。

50以上のProviderプリセットを内蔵しており、READMEではAWS Bedrock、NVIDIA NIM、各種コミュニティrelayなどが挙げられている。ユーザーはAPI keyをコピーしてワンクリックでインポートし、画面上で切り替えられる。

実用的なポイントは次の通りだ。

Providerをワンクリックで追加できる。
Providerをドラッグで並べ替えられる。
システムトレイから素早く切り替えられる。
Providerのインポートとエクスポートに対応する。
一部の共通Providerは複数アプリへ同期できる。

多くの人にとって、この機能だけでも十分に魅力がある。AIコーディングツールの日常利用で問題になるのは、「モデルを使えない」ことではなく、「今日このkeyをどのツール、どのendpoint、どのアカウントで使うのか」が混乱することだからだ。

ローカルプロキシとフェイルオーバー

設定ファイルを書き換えるだけでなく、CC Switch はローカルプロキシモードも提供する。

この機能の要点は次の通りだ。

Providerのホットスイッチ。
フォーマット変換。
自動フェイルオーバー。
サーキットブレーカー。
Providerのヘルスチェック。
リクエスト補正。

簡単に言えば、対象ツールに設定を書き込むだけでなく、間にローカルプロキシ層を挟み、異なるツールがそのプロキシ経由でモデルサービスにアクセスできるようにする。

これは複数Providerを使うユーザーにとって便利だ。あるサービスが落ちたら別のものへ切り替える。あるモデルが高ければ安いものに変える。リクエスト形式が合わない場合も、プロキシ層で適配できる。

MCP、Prompts、Skills

CC Switch の重要な第二層の機能は、MCP、Prompts、Skillsの一元管理だ。

MCP

複数アプリ間でMCP serverを管理できる統一MCPパネルを提供し、双方向同期とDeep Linkインポートにも対応する。

これはMCPを使っているユーザーにはかなり実用的だ。MCP serverが増えるほど、設定は複数のクライアントに散らばりやすい。統一パネルがあれば、重複設定を減らし、移行もしやすくなる。

Prompts

Prompts部分はMarkdown編集に対応し、異なるツール間で対応するファイルを同期できる。例えば次のようなファイルだ。

CLAUDE.md
AGENTS.md
GEMINI.md

これらは本質的にはAgent向けのプロジェクト説明書だ。一元管理できれば、チームルール、プロジェクトの約束事、グローバルプロンプトをより保守しやすくなる。

Skills

SkillsはGitHubリポジトリやZIPファイルからワンクリックでインストールできる。カスタムリポジトリ管理、シンボリックリンク、ファイルコピーにも対応する。

Claude Code、Codex、OpenClawのようなツールを同時に使う場合、Skillsは複数ディレクトリに散らばったファイル群になりやすい。CC Switch はそれらを集約し、保守コストを下げる。

セッションとワークスペース

READMEではSession ManagerとWorkspace関連の機能にも触れられている。

複数アプリ内のセッション履歴を閲覧、検索、復元できる。AIコーディングツールを長期的に使う人にとって、セッション管理はかなり重要だ。価値のある文脈、デバッグ過程、案の比較が、古い会話の中に埋もれていることが多いからだ。

さらにOpenClaw向けにWorkspace editorも提供し、AGENTS.md、SOUL.md などのagentファイルを編集でき、Markdownプレビューも備える。

これは CC Switch が単なる「key切り替えツール」ではなく、AI Agentワークステーションの方向へ拡張していることを示している。

クラウド同期とデータ保存

CC Switch はDropbox、OneDrive、iCloud、NAS、WebDAV経由でProviderデータを同期できる。

ローカルのデータ保存場所も明確だ。

データベース：~/.cc-switch/cc-switch.db
ローカル設定：~/.cc-switch/settings.json
自動バックアップ：~/.cc-switch/backups/
Skills：~/.cc-switch/skills/
Skillバックアップ：~/.cc-switch/skill-backups/

主要データソースとしてSQLiteを使い、原子的な書き込みと自動バックアップを重視している。目的は、切り替えや書き込みの際に設定ファイルが壊れることを避けることだ。

この設計はヘビーユーザーにとって重要だ。設定管理ツール自体が設定を書き壊した場合、影響を受けるのはすべてのAIコーディングツールだからだ。

インストール方法

CC Switch はTauri 2ベースのクロスプラットフォームデスクトップアプリだ。

おおよそのシステム要件は次の通り。

Windows：Windows 10以降
macOS：macOS 12 Monterey以降
Linux：Ubuntu 22.04+、Debian 11+、Fedora 34+などの主要ディストリビューション

Windowsユーザーは .msi インストーラーまたはポータブル版の圧縮パッケージをダウンロードできる。

macOSユーザーはHomebrewでインストールできる。

1
2

brew tap farion1231/ccswitch
brew install --cask cc-switch

更新は次の通り。

`1`	`brew upgrade --cask cc-switch`

Linuxユーザーは .deb、.rpm、AppImageを選べる。Arch Linuxユーザーは paru -S cc-switch-bin でもインストールできる。

2026年5月6日時点で、リポジトリページに表示されている最新releaseは CC Switch v3.14.1 で、公開日は2026年4月23日だ。

技術スタック

リポジトリ構成を見ると、CC Switch は典型的なTauriデスクトップアプリだ。

フロントエンド：React 18、TypeScript、Vite、TailwindCSS、TanStack Query、shadcn/ui
バックエンド：Tauri 2、Rust、SQLite、Tokio
テスト：Vitest、MSW、Testing Library

主な設計パターンは次の通り。

SQLiteをSingle Source of Truthとして使う。
デバイス単位のローカル設定はJSONで保存する。
切り替え時に対象ツールのlive configへ書き込む。
現在のProviderを編集する際はlive configから回填する。
一時ファイルとrenameを使って原子的に書き込む。
データベース接続をロックし、並行書き込み問題を避ける。

この構成から、プロジェクトは単なるスクリプトではなく、長期利用を前提にしたデスクトップツールとして設計されていることがわかる。

誰に向いているか

CC Switch が向いているのは次のようなユーザーだ。

Claude Code、Codex、Gemini CLI、OpenCode、OpenClawを同時に使う。
公式アカウント、サードパーティrelay、ローカルモデル、チームProviderを頻繁に切り替える。
すでにMCPを多用し始めている。
CLAUDE.md、AGENTS.md、GEMINI.md を統一して保守したい。
Skillsを頻繁にインストール、テスト、移行する。
複数ツールのセッション履歴や利用状況を見たい。

もしAIコーディングツールを1つだけ使い、常に公式ログインで、Provider、MCP、Skillsをあまり触らないなら、価値はそれほど明確ではないかもしれない。

しかしすでに「複数ツール、複数アカウント、複数Provider、複数プロジェクト」の状態に入っているなら、細かな設定作業をかなり減らせる。

注意点

この種のツールは便利だが、境界も意識する必要がある。

第一に、複数のAI CLI設定を管理するため、このツールとその書き込みロジックを信頼できるか確認する必要がある。

第二に、API key、relay endpoint、MCP serverはいずれも機微な設定だ。クラウド同期を有効にする前に、同期先ディレクトリやWebDAVサービス自体が安全で信頼できるか確認したい。

第三に、Providerを切り替えた後、多くのツールでは変更を反映するためにターミナルやCLIの再起動が必要になる。READMEでは、Claude CodeはProviderデータのホットスイッチに対応するとされているが、他のツールでは通常再起動が必要だ。

第四に、公式ログインへ戻す場合は、プロジェクト説明に沿ってofficial providerを追加し、対応するツールのログインフローを改めて実行するのがよい。

まとめ

CC Switch の価値は、また別のAIコーディングツールを作ったことではない。AIコーディングのエコシステムが、すでに複数ツール共存の段階に入ったという現実を認めている点にある。

Claude Code、Codex、Gemini CLI、OpenCode、OpenClawにはそれぞれ独自の設定システムがあり、MCP、Skills、Prompts、Providerも急速に広がっている。設定を手作業で変え続けるやり方は、いずれ負担になる。

CC Switch はこれらを1つのデスクトップアプリに集約し、Providerの切り替え、MCPの同期、Skillsの管理、プロンプトファイルの保守、セッション確認をより簡単にする。AIコーディングを重く使う人にとって、この種のツールは「任意の小道具」から「日常の基盤」へ変わっていく可能性が高い。

参考資料

farion1231/cc-switch

Claude Code の HERMES.md 課金トラブルは何だったのか

Sat, 02 May 2026 11:19:23 +0800

Claude Code では最近、典型的な課金トラブルがありました。ユーザーは CLI を起動しただけで、明示的なリクエストをまだ送っていなかったにもかかわらず、ローカルの HERMES.md ファイルが読み込まれ、大きな費用が発生しました。

この件が重要なのは、特定ユーザーの損失額そのものではありません。AI コーディングツールの新しいリスクを示しているからです。ツールが自動で文脈を読むなら、ローカルファイルは実際の token コストになり得ます。

何が起きたのか

公開 issue によると、ユーザーは作業ディレクトリに大きな HERMES.md ファイルを置いていました。Claude Code を起動すると、CLI はプロジェクト文脈をスキャンして読み込みます。問題は、このファイルが自動的に文脈へ含まれ、API 使用量として計上されたことです。

ユーザーはそのファイルをモデルに処理させるよう明示していませんでしたが、課金はすでに発生していました。さらに厄介なのは、この種の動作がツール初期化や文脈準備の段階で起きるため、ユーザーがすぐに費用発生に気づけないことです。

Anthropic はその後 issue で、異常な費用を返金し、追加クレジットも提供すると返信しました。この対応により問題は少なくとも公式に確認され、処理されたと言えます。ただし、AI CLI の「自動文脈」は無料ではない、という点は残ります。

なぜ HERMES.md が問題になったのか

HERMES.md そのものが本質ではありません。長いログ、エクスポート文書、テストデータ、データベース dump、生成レポートなど、どんな大きなファイルでも同じ問題を起こし得ます。

本当の問題は三つの要素が重なったことです。

Claude Code がプロジェクト文脈を自動で読む。
読まれるファイルが大きい場合がある。
文脈 token が課金経路に入る。

ファイルが十分大きければ、ツールが「ついでに持ち込んだ」だけでも目に見える費用になります。token 課金のモデルでは、自動化が強いほど境界を明確にする必要があります。

これは普通の bug ではない

普通の CLI bug なら、コマンド失敗、出力ミス、機能不全で済むことが多いです。課金 bug は、ユーザーの請求額に直接影響するため、より敏感です。

AI コーディングツールでは、課金境界が曖昧になりがちです。

システムプロンプトが token を消費する。
プロジェクトルールが token を消費する。
自動で読まれたファイルが token を消費する。
ツール呼び出し結果が token を消費する。
リトライ、圧縮、要約もさらに token を消費し得る。

ユーザーには「ツールを起動しただけ」または「一回の会話」に見えても、裏側では複数回のリクエストと大量の文脈送信が発生している可能性があります。

ユーザー側の防御策

Claude Code、Codex、Cline のような AI コーディングツールを使うなら、まず次のことを確認したいところです。

大きなファイルをプロジェクトルートに直接置かない。
ログ、エクスポートデータ、ビルド成果物、一時ファイルを ignore ルールに入れる。
.ignore、文脈除外、ファイル許可リストのような設定があるか確認する。
予算アラートや使用量制限を有効にする。
大きなリポジトリで初めて実行する前に、小さなディレクトリで試す。

リポジトリ内に大きなファイルを残す必要がある場合は、ツールにそれらを読まないよう明示するのが安全です。プロジェクトルールにも、ログ、dump、データセット、アーカイブ、大きな Markdown を能動的に読まないよう書いておけます。

ツール側が改善すべきこと

この種の問題は、ユーザーの注意だけに頼るべきではありません。ツール側にも明確な境界が必要です。

よりよい設計には次のようなものがあります。

初期化段階で大きなファイルを暗黙に課金対象へ入れない。
非常に大きいファイルを自動で読む前に確認を求める。
CLI が今回の推定 token 数と費用範囲を表示する。
よくある大きなファイルや生成ディレクトリを標準で無視する。
異常な token 急増に保護しきい値を設ける。

AI コーディングツールが自動エージェントに近づくほど、コストの透明性が重要になります。そうでないと、ユーザーは一回の操作でいくらかかるのか判断できません。

まとめ

Claude Code の HERMES.md 課金トラブルは、自動文脈と従量課金の衝突です。

ユーザーにとって大事なのは、プロジェクト文脈を管理することです。大きなファイルを AI ツールに標準で見せないこと、予算と使用量に上限を設けること。ツール提供側には、自動ファイル読み込みに対して見えるコスト表示と保護機構が必要です。

参考：

DeepSeek V4 の値下げは AI Agent のコストモデルをどう書き換えるか

Fri, 01 May 2026 19:47:47 +0800

DeepSeek V4 の発表は、特別に大きな話題を作ったわけではありません。大規模な発表会もなく、すべての競合を一目で圧倒するようなベンチマークの物語もありませんでした。しかし数日後、本当に業界へ影響する部分が見え始めました。連続的な値下げです。

今回の変化で重要なのは、「モデルが少し強くなった」ことではなく、「利用コストが別の水準まで下がった」ことです。 Token 価格が、普通の Agent タスクなら数毛から数元で完了できるほど低くなると、多くの Coding Plan や Token Plan のビジネスロジックは見直しを迫られます。

発表当日は爆発的ではなかった

DeepSeek V4 に対する最初の反応は、そこまで熱狂的ではありませんでした。多くの人は R1 のような強い衝撃を期待していました。ベンチマークの全面的なリード、国産計算資源の検証、マルチモーダルと Agent 能力の同時爆発です。しかし実際に発表されると、それは堅実なアップグレードに近いものでした。

V4 Pro は確かに強いモデルです。特にコード、数学、長文コンテキスト、agentic coding では良い性能を見せます。ただし、同種のモデルを一瞬で色あせさせるような製品ではありません。そのため発表当日の世論には少し気まずさがありました。褒めたいけれど、十分に爆発的な切り口が見つかりにくかったのです。

本当の転換点は発表当日ではなく、その後の価格調整でした。

連続値下げこそが重要

DeepSeek V4 の発表後、価格は連続して下がり始めました。 DeepSeek の公式価格ページと元記事の整理によると、当時のおおよその価格は次のとおりです。

DeepSeek V4 Flash：入力 100 万 Token あたり約 1 元。キャッシュヒット後は 100 万 Token あたり約 2 分；
DeepSeek V4 Pro：入力 100 万 Token あたり約 3 元。キャッシュヒット後は 100 万 Token あたり約 2.5 分；
全シリーズの入力キャッシュヒット価格は、初回価格の 1/10 に低下；
V4 Pro は一時 75% 割引期間にあり、割引は 2026 年 5 月 31 日 23:59 まで延長されました。

米ドルの API 価格で見ると、さらに直感的です。

モデル	キャッシュヒット入力	非キャッシュ入力	出力	コンテキスト
`deepseek-v4-flash`	$0.0028 / 100万 Token	$0.14 / 100万 Token	$0.28 / 100万 Token	1M
`deepseek-v4-pro` プロモーション価格	$0.003625 / 100万 Token	$0.435 / 100万 Token	$0.87 / 100万 Token	1M
`deepseek-v4-pro` 通常価格	$0.0145 / 100万 Token	$1.74 / 100万 Token	$3.48 / 100万 Token	1M

ここで注意すべき点が 2 つあります。

第一に、V4 Pro の $0.435 / $0.87 はプロモーション価格であり、長期的な通常価格ではありません。 DeepSeek の公式説明では、この 75% 割引は 2026 年 5 月 31 日 15:59 UTC まで延長されています。

第二に、Agent のコストモデルで重要なのはキャッシュヒット価格です。 Flash のキャッシュヒット入力は $0.0028 / 100万 Token まで低く、Pro のプロモーション期間中のキャッシュヒット入力は $0.003625 / 100万 Token です。これは、繰り返し使われるプロジェクトコンテキスト、ツール定義、システムプロンプト、履歴要約が、完全な入力価格で課金されなくなることを意味します。

この価格のもっとも重要な点は、多くのタスクで Token コストが「気になりにくくなる」ことです。以前の開発者は、1 回の Agent タスクが大量のコンテキストを消費し、コードを何度も読み書きし、ツールを頻繁に呼び出すことを心配していました。今はキャッシュヒット率が十分に高ければ、コストをかなり低く抑えられます。

GPT、Claude との価格比較

DeepSeek 自体の価格だけを見ても、差はまだ感じにくいかもしれません。同時期によく使われるクローズドモデルと並べると、違いはより明確になります。

モデル	入力	キャッシュ入力	出力	適した場面
`deepseek-v4-flash`	$0.14 / M	$0.0028 / M	$0.28 / M	高頻度 Agent、通常の coding、バッチタスク
`deepseek-v4-pro` プロモーション価格	$0.435 / M	$0.003625 / M	$0.87 / M	複雑な coding、計画、事実確認
`deepseek-v4-pro` 通常価格	$1.74 / M	$0.0145 / M	$3.48 / M	プロモーション終了後の Pro コスト基準
GPT-5.5	$5 / M	$0.50 / M	$30 / M	高品質な複雑タスク、汎用推論
GPT-5.4	$2.50 / M	$0.25 / M	$15 / M	プログラミングと専門タスクの中位選択肢
GPT-5.4 mini	$0.75 / M	$0.075 / M	$4.50 / M	低コストの汎用/サブタスクモデル
Claude Opus 4.7	$5 / M	$0.50 / M	$25 / M	高品質な執筆、複雑推論、長時間タスク
Claude Sonnet 4.6	$3 / M	$0.30 / M	$15 / M	プログラミング、Agent、総合タスク
Claude Haiku 4.5	$1 / M	$0.10 / M	$5 / M	軽量タスク、要約、分類

この表で最も目立つのは出力価格です。 Agent はコンテキストを読むだけでなく、計画、パッチ、説明、ログ、次のアクションを継続的に生成します。出力が多い場合、DeepSeek V4 Pro のプロモーション価格 $0.87 / M は、GPT-5.5 の $30 / M や Claude Sonnet 4.6 の $15 / M と比べて、差がどんどん広がります。

V4 Pro の通常出力価格 $3.48 / M で計算しても、GPT-5.4、GPT-5.5、Claude Sonnet / Opus より明らかに低い水準です。タスクを Flash で処理できるなら、出力価格はさらに $0.28 / M まで下がります。

キャッシュ入力の差はさらに極端です。 DeepSeek V4 Flash のキャッシュ入力は $0.0028 / M である一方、GPT-5.5 と Claude Opus 4.7 のキャッシュ入力はいずれも $0.50 / M です。これは同じ桁の話ではありません。同じコードリポジトリを繰り返し読む Agent にとって、この差は通常のチャットよりも重要です。

Agent タスクが特に影響を受ける理由

AI Agent は普通のチャットとは違います。普通のチャットはたいてい一問一答で、入力コンテキストは比較的限られています。 Agent タスクは、プロジェクトファイルを繰り返し読み、計画を生成し、ツールを呼び出し、結果を確認し、さらにコードを修正します。

この種のタスクには 2 つの特徴があります。

Token 消費が大きい；
繰り返しコンテキストが多い。

2 点目が非常に重要です。コードプロジェクトでは、モデルは同じファイル群、ディレクトリ構造、エラーログ、変更結果を何度も読みます。プラットフォームがキャッシュヒットをサポートしていれば、繰り返し入力のコストは大幅に下がります。

元記事では実際の体験として、DeepSeek V4 Pro と Flash を Claude Code のようなツールに接続し、プロンプトリポジトリを取得してローカル検索サイトを作らせた例が紹介されています。タスクは最終的に完了し、総コストは 8 毛強ほどで、そのうち Pro のキャッシュヒット率は 98.7% に達しました。

この例は現実的な問題を示しています。Agent タスクが「同じプロジェクトを中心に繰り返し作業する」ほど、キャッシュヒットの価値は高くなります。 Web サイト生成、bug 修正、フロントエンド修正が数毛から数元で済むなら、サブスクリプションプランの魅力は下がります。

簡略化したタスクで差を見積もることもできます。 1 回の coding agent タスクが次を含むと仮定します。

50 万 Token の入力。そのうち 80% がキャッシュヒット可能；
5 万 Token の出力；
ツール呼び出し、検索、プラットフォーム上乗せ分は計算せず、モデル Token コストだけを見る。

おおよそのコストは次のとおりです。

モデル	推定コスト
DeepSeek V4 Flash	約 $0.03
DeepSeek V4 Pro プロモーション価格	約 $0.09
DeepSeek V4 Pro 通常価格	約 $0.36
GPT-5.4 mini	約 $0.30
GPT-5.4	約 $1.01
GPT-5.5	約 $1.75
Claude Sonnet 4.6	約 $1.11
Claude Opus 4.7	約 $1.65

この見積もりは、DeepSeek がすべてのタスクで優れているという意味ではありません。モデル品質、ツール呼び出しの安定性、長文コンテキスト検索能力、コードスタイル、事実の信頼性は個別に評価する必要があります。ただしコスト面では、DeepSeek V4 は「Agent にもう数ラウンド走らせる」ことの限界コストをかなり低くしました。これにより開発者は、毎回 Token 請求を心配するのではなく、より長いワークフロー、より頻繁なセルフチェック、より多くの候補案を設計しやすくなります。

Coding Plan と Token Plan の違い

多くの AI 製品はいま、Coding Plan と Token Plan という 2 種類のプランを提供しています。

大まかな違いは次のとおりです。

Coding Plan は通常、主にプログラミング向け；
Token Plan は通常、STT、TTS、画像生成、検索、embedding、RAG など、より多くの機能を含む；
STT は音声から文字への変換；
TTS は文字から音声への変換；
Coding Plan はユーザーをプログラミング場面に制限しがちで、他の機能は別途購入が必要になることが多い。

ビジネスの観点では、Coding Plan はビュッフェに近いものです。ユーザーは固定料金を前払いし、ベンダーは大多数の人が枠を使い切らないことに賭けます。多く使う人も少なく使う人もいて、平均するとプラットフォームは利益を出せます。

しかし従量制の Token 価格が十分に低くなると、ユーザーは計算し始めます。なぜ必ずプランを買わなければならないのか。 1 か月の実際の利用コストが数元から十数元程度なら、40 元や 200 元のプランは必ずしも割に合いません。

値下げがサブスクリプションモデルを揺さぶる理由

サブスクリプションプランが成立するには前提があります。ユーザーが単発利用を高いと感じるか、毎回の呼び出しコストを計算したくないことです。 Token 価格が高いとき、プランは安心に見えます。 Token 価格がほとんど気にならないほど低くなると、従量課金のほうが自然になります。

DeepSeek V4 の値下げは、底のコストを見せたようなものです。

Agent タスクは非常に安くできる；
長文コンテキストは必ずしも使えないほど高くない；
キャッシュヒットでコストを大きく下げられる；
普通の開発者は固定サブスクリプションを必ずしも必要としない；
モデルの入口は「プラン型プラットフォーム」から「低価格 API」へ移り得る。

これは Coding Plan を提供するプラットフォームにとって不快な変化です。従量呼び出しのほうが安く自由だとユーザーが気づけば、ひとつのプラットフォームのプランに縛られる必要はありません。

Flash と Pro をどう選ぶか

DeepSeek V4 の実用的な考え方のひとつは、Flash と Pro を分担して使うことです。

Flash は高頻度、軽量、反復可能なタスクに向いています。

bug 修正；
フロントエンド作成；
スクリプト作成；
通常のコード理解；
長いコンテキスト内の一般的な情報整理；
大量のサブタスク実行。

Flash は安く、速く、同じく長いコンテキストをサポートします。日常的な coding agent では、多くのタスクで最初から Pro を使う必要はありません。

Pro は複雑な判断やフォールバックタスクに向いています。

複数ラウンドの計画；
複雑な Agent ワークフロー；
複数回の function call；
事実確認；
財務・経済リサーチ；
より強い知識と判断力が必要なコンテンツ生成；
高リスクなコード変更。

合理的な構成は、Flash が量をこなし、Pro がフォールバックを担当する形です。通常タスクはまず Flash で始め、長期計画、複雑な判断、事実確認、複数ツールの協調が必要になったら Pro に切り替える。こうすればコストを抑えつつ、モデル品質も保てます。

DeepSeek がこの価格を出せる理由

DeepSeek は多くの大手企業と事業構造が異なります。 EC、SNS、ショート動画、クラウドコンピューティング、スマートフォン、自動車、オフィススイート、OS、ブラウザ、大規模な企業向け SaaS エコシステムを持っていません。

つまり、ユーザーを完全なプラットフォーム内に閉じ込める必要がありません。安いテキストモデル能力だけを売ることができます。他の機能は、必要に応じてどこを呼び出してもよいのです。

大手企業のロジックは通常異なります。その Coding Plan や Token Plan を買うと、クラウド、検索、画像生成、音声、データベース、開発ツールのエコシステムへ引き込まれます。プランは単純にモデルを売るものではなく、ユーザーの入口を取りに行くものです。

DeepSeek の戦い方はより直接的です。テキストモデルの価格を下げ、Agent のデフォルトモデル入口になることを狙います。デフォルト入口を取れれば、多くの開発者とツールチェーンは自然にそれへ適応していきます。

オープンモデルとデフォルト入口

DeepSeek V4 がオープンモデル路線を維持するなら、サードパーティのクラウドベンダーやプラットフォームが自前でデプロイし、サービスを提供する可能性があります。 DeepSeek にとって、それは普及でもあり、同時に流量の分散でもあります。

低価格の公式 API の意味はここにあります。公式価格がすでに十分低ければ、他のプラットフォームがデプロイできたとしても、価格面で明確な優位を出すのは難しくなります。ユーザーは、デフォルトで安く安定した入口を直接使う傾向になります。

Agent ツールでは特にそうです。 Agent タスクは長文コンテキスト、キャッシュ、ツール呼び出し、安定したスループットに依存します。あるモデルがこれらの場面で十分安ければ、デフォルト選択肢になる可能性があります。

Coding Plan は完全に無用ではない

これは Coding Plan がすぐ消えるという意味ではありません。それに合うユーザーはまだいます。

もし一部のユーザーが本当に高頻度で、毎日プランの上限まで使うなら、固定サブスクリプションはまだ得かもしれません。ビュッフェと同じで、誰も元を取れないなら、ユーザーも買おうとはしません。

ただし問題は、ほとんどのユーザーがそのような極端な高頻度ユーザーではないことです。低頻度ユーザー、軽量な開発者、たまにスクリプトを書いたりプロジェクトを直したりする人には、従量課金のほうが向いています。 DeepSeek が従量コストを下げると、プランの魅力は弱まります。

今後は、より階層化された選択が起こりやすくなります。

高頻度のヘビーユーザーは Coding Plan を買い続ける；
普通のユーザーは低価格 API へ移る；
Agent ツールはタスクに応じて Flash / Pro を自動選択する；
プラットフォームのプランは、ワークフロー、IDE 統合、デプロイ、チーム管理、セキュリティ監査など、モデル以外の価値をより多く提供する必要がある。

まとめ

DeepSeek V4 の発表は、ベンチマークによって最大の衝撃を作ったわけではありません。本当に業界の期待を変えたのは、その後の値下げでした。

入力 Token とキャッシュヒット価格が非常に低くなると、AI Agent の利用コストは変わります。これまで高価に見えていた長文コンテキスト、コードプロジェクト分析、複数ラウンドのツール呼び出しが、今では数毛から数元の日常的な消費になる可能性があります。

これは Coding Plan と Token Plan のビジネスロジックを直接揺さぶります。ユーザーが従量課金で、モデルとツールを自由に組み合わせられ、さらにコストも十分低いなら、特定のプラットフォームプランに縛られる必要はありません。

DeepSeek V4 が今回本当に動かしたのは、モデル能力ランキングだけではなく、AI Agent のコスト構造とデフォルト入口をめぐる競争です。

参考情報：

mattpocock/skills：AI コーディング Agent 向けの実用スキル集

Fri, 01 May 2026 03:43:20 +0800

mattpocock/skills は、Matt Pocock が公開している AI コーディング agent skills のコレクションです。

これは完全なアプリケーションでも、新しいチャットクライアントでもありません。AI コーディングアシスタントに使わせるための作業スキル集です。考え方は実用的です。AI コーディングでよく起こる問題を小さなスキルに分解し、Agent が適切なタスクで呼び出せるようにします。毎回巨大なプロンプトで無理に支えるのではありません。

Claude Code、Codex、Cursor、または類似の AI コーディングツールをよく使うなら、この種の skills は注目する価値があります。AI コーディング体験に本当に影響するのは、「モデルがコードを書けるか」だけではなく、自分の作業方法に沿ってタスクを進められるかだからです。

解決する問題

AI コーディングアシスタントは強力ですが、問題も起こしやすいです。

よくある状況は次のとおりです。

要件を理解する前にコード変更を始める
一度に多すぎるファイルを変更する
説明は多いが、実際に有用な行動が少ない
エラー後に場当たり的に試す
テストやチェックをすぐに実行しない
プロジェクト内の既存パターンを無視する
タスク完了のために不要な抽象を導入する
コードを書いた後に本当にリスクを review しない

これらは必ずしもモデル能力不足ではありません。ワークフローが十分に制約されていないことが原因の場合も多いです。

mattpocock/skills の価値は、こうした失敗パターンを再利用可能な操作方法に分解し、Agent が場面に応じてより経験あるエンジニア協作者のように振る舞えるようにすることです。

Skills とは何か

AI Agent の文脈では、skill は再利用可能なタスク説明、作業方法、専門的なフローとして理解できます。

必ずしもコードプラグインである必要はなく、外部サービスを呼び出す必要もありません。多くの場合、skill は明確なルールセットです。

いつ使うか
まず何をするか
何をしないか
何を出力するか
タスク完了をどう判断するか

これは通常のプロンプトテンプレートに似ていますが、粒度は「タスク能力」に近いものです。

通常のプロンプトテンプレートは、ユーザーが毎回一時的にコピーして貼り付けるものです。Skills は agent ツールボックスの一部として、Agent がタスクに応じて適切なフローを選ぶ形に向いています。

小さく組み合わせ可能である理由

README では、これらの skills が小さく組み合わせ可能であることを強調しています。

これは重要な方向性です。

1 つの skill がすべてを担当しようとすると、すぐに新しい巨大プロンプトになります。長く、曖昧で、保守しにくいものです。小さなスキルの利点は境界が明確なことです。

たとえば 1 つの skill は次のようなことだけに集中できます。

先に計画する
TypeScript エラーを修正する
テストを実行し、結果に基づいて修正する
コード review を行う
プロジェクト規約を要約する
プロンプトを改善する
不要な抽象を取り除く

これらのスキルはタスクに応じて組み合わせられます。単純なタスクなら 1 つ、複雑なタスクなら複数をつなげます。

これは実際のエンジニアリング作業に近いです。すべての問題を同じフローで処理するのではなく、問題に応じてツールを選びます。

エンジニアの制御を残す

このリポジトリの重要な方向性の一つは、エンジニアが制御権を持ち続けることです。

AI コーディングは、2 つの極端に寄りやすいです。

1 つ目は完全に手動です。AI は数行のコードを書く手伝いをするだけで、コンテキスト、計画、検証はすべて自分が監視します。

2 つ目は完全に放任です。タスクを Agent に投げ、大きく変更させ、最後にレビューしづらい diff と向き合います。

skills はその中間に、より安定した位置を作ります。

AI により多くの反復フローを任せつつ、ルールで制限します。

タスクを理解してから手を動かす
関連ファイルを読んでから変更する
変更範囲を制御可能にする
不確実な場合は報告する
変更後に検証する
見せつけるために無関係なコードをリファクタリングしない

これは AI を弱めるのではありません。AI の行動を人間がレビューし、引き継ぎやすくするものです。

アラインメント問題

AI コーディング失敗の最初の種類は、アラインメント失敗であることが多いです。

ユーザーが求めているのは具体的な変更ですが、Agent はそれを大きなリファクタリングとして理解することがあります。ユーザーは Bug 修正だけを望んでいるのに、スタイルまで変更することがあります。既存アーキテクチャに従ってほしいのに、新しいパターンを導入することもあります。

Skills はタスク開始時に Agent に次のことをさせられます。

目的を言い直す
影響範囲を見つける
既存の実装パターンを識別する
計画を出す
何をしないかを明確にする

これはエンジニアが作業開始前に行うセルフチェックに似ています。

Agent がタスク境界を明確にしないままコードを書き始めると、後でどんどんズレやすくなります。

フィードバックループ問題

AI のコード生成は一回だけに頼るべきではありません。

実際の開発では、フィードバックループが重要です。

小さく変更する
テストまたは型チェックを実行する
エラーを見る
修正する
再検証する

多くの Agent は途中のフィードバックを飛ばすために失敗します。一度に多くを変更し、感覚で「動くはず」とまとめます。

Skills はフィードバックループを明示的にフローへ書き込めます。たとえば Agent に次のことを要求できます。

変更後に関連チェックを実行する
チェックが失敗したら、まずエラーメッセージを読む
無関係なファイルを盲目的に変更しない
各修正後に再検証する
最後に検証結果を報告する

これにより AI コーディングは、一回限りの作文ではなく本物のデバッグに近づきます。

アーキテクチャ制御問題

AI は抽象を生成するのが得意で、過剰に抽象を生成するのも得意です。

小さな要件を満たすために、サービス層、ヘルパー関数、設定オブジェクト、型ラッパー、アダプターを新しく作り、最終的に要件そのものより複雑なコードにしてしまうことがあります。

この問題は大規模プロジェクトで特に危険です。AI が生成した抽象は「専門的」に見えますが、既存のプロジェクトスタイルに合わず、保守コストを増やす可能性があります。

良い skills は Agent に次のことを思い出させます。

既存パターンを優先する
不必要な新しい抽象を導入しない
無関係な領域をついでにリファクタリングしない
変更をタスク規模に合わせる
コードを理解してから構造を設計する

これにより、「見た目はエンジニアリングっぽいが実際は保守しにくい」出力を減らせます。

Review skill が重要な理由

コードを書くこととコードを review することは別の状態です。

Agent がコードを書くとき、自分の実装が成立することを説明しがちです。なぜこの変更で動くかは説明しますが、必ずしもリスクを探すわけではありません。

Review skill の意味は、Agent の役割を切り替えることです。

潜在 Bug を探す
振る舞いの回帰を探す
足りないテストを探す
境界条件を探す
複雑度の上昇を探す
既存規約と不一致な箇所を探す

これは AI コーディングで重要です。AI はコードを高速に生成するため、review がないとユーザーは大量の diff に埋もれやすくなります。

良い review 出力は、まず問題を列挙すべきです。先に実装を褒める必要はありません。エンジニアがその変更をマージできるか判断する助けになるべきです。

通常の rules ファイルとの違い

多くの AI コーディングツールは rules、instructions、memory をサポートしています。

これらのファイルは通常、長期ルールを記録します。

プロジェクト技術スタック
命名規約
テストコマンド
変更してはいけないディレクトリ
回答スタイルの好み

Skills はよりタスクフローに寄っています。

rules は Agent に「長期的にどう振る舞うべきか」を伝えます。skills は Agent に「この種類のタスクをどう実行すべきか」を伝えます。

両方を一緒に使うのがよいです。

たとえば rules にプロジェクトが pnpm test を使うと書き、review skill で変更後にテストカバレッジを確認するよう求めます。すると Agent はコマンドだけでなく、いつ使うべきかも理解します。

向いている場面

mattpocock/skills のようなリポジトリは次の場面に向いています。

AI コーディングツールを頻繁に使う
Agent に実コードベースを扱わせる
AI の範囲外変更を減らしたい
Agent により積極的に結果を検証させたい
自分のエンジニアリング習慣を skills にしたい
他人の agent workflows 設計を学びたい
一時的なプロンプト群を保守可能な skill 集合に整理したい

たまに AI に小さな関数を書かせるだけなら、skills を専用に維持する必要はないかもしれません。

しかし AI を長期的な開発パートナーとして扱うなら、skills は徐々に重要になります。Agent に再利用可能な作業方法を持たせるものだからです。

このリポジトリから学べること

各 skill を直接使わなくても、このリポジトリからいくつか学べます。

第一に、失敗パターンを書き出すことです。

AI が間違えたときにその場で不満を言うだけではなく、よく間違えるパターンをルールに整理します。次回は skill に先回りして防がせます。

第二に、スキルは短くすることです。

1 つの skill は、1 つの明確な問題を解くのが理想です。短いほど正しく呼び出されやすく、保守しやすくなります。

第三に、出力形式を明確にすることです。

Agent に先に計画を列挙し、次に実行し、最後に検証結果をまとめてほしいなら、その構造を明確に書きます。曖昧な要求は曖昧な結果を生みます。

第四に、人間が引き継ぐポイントを残すことです。

良い skill は AI を一人で遠くまで走らせるべきではありません。不確実性、影響範囲の拡大、テスト失敗、プロダクト判断が必要な場合は、止まって状況を説明させるべきです。

利用時の注意

第一に、すべてを skill 化しないことです。

skills が多すぎるとシステムは複雑になり、Agent もどれを選ぶべきか分からなくなります。まずは頻度が高く、痛みの大きい場面から始めるのがよいです。

第二に、skills は反復改善が必要です。

最初に書いた skill が良いとは限りません。AI の実行結果を見て、少しずつ削り、追加し、書き直します。

第三に、skill にエンジニアリング判断を置き換えさせないことです。

Skill はフローを改善できますが、実装の正しさを保証するものではありません。テスト、review、ビルドチェック、人間の判断は依然として重要です。

第四に、Agent ごとの差に注意することです。

Claude Code、Codex、Cursor、Copilot は instructions、skills、rules のサポート方法が異なります。同じ考え方は再利用できますが、具体的な形式はツールに合わせて調整する必要があります。

参考

mattpocock/skills

最後に

mattpocock/skills が注目に値するのは、その中の一つの魔法のプロンプトではありません。エンジニアリング経験を小さなスキルに分解し、Agent に場面ごとに組み合わせて使わせるという実用的な AI コーディングの考え方です。

AI コーディングがたまの補助から日常ワークフローになると、skills は Agent を制約し、エンジニアの制御を保ち、フィードバック品質を高める重要な道具になります。

free-claude-code：プロキシで Claude Code を OpenRouter、DeepSeek、ローカルモデルへ接続する

Fri, 01 May 2026 03:41:49 +0800

free-claude-code は、Claude Code 向けの Anthropic-compatible proxy です。

考え方は Claude Code を破解することでも、公式の無料 Claude サービスを提供することでもありません。ローカルで Anthropic API の形に互換性を持つプロキシサービスを起動し、Claude Code からのリクエストを他のモデルバックエンドへ転送します。README では NVIDIA NIM、OpenRouter、DeepSeek、LM Studio、llama.cpp、Ollama などが挙げられています。

簡単に言うと、Claude Code のターミナル体験は好きだが、モデルリクエストは別の provider やローカルモデルへ接続したい、という問題を解決するものです。

解決する問題

Claude Code の対話体験は開発タスクに向いています。

ターミナル内でコードを読み、ファイルを変更し、コマンドを実行し、プロジェクトコンテキストに基づいてタスクを進められます。ただし、多くのユーザーは常に同じモデルバックエンドを使いたいとは限りません。

OpenRouter 上の異なるモデルを試したい
DeepSeek のようなモデルでコストを下げたい
リクエストをローカル Ollama に接続したい
LM Studio や llama.cpp でローカルモデルを動かしたい
開発環境でプロキシ入口を統一したい
Claude Code ワークフロー内で異なるモデルの挙動を比較したい

free-claude-code の位置づけは、Claude Code とこれらのモデルサービスの間に互換プロキシを置くことです。

Claude Code は Anthropic 風にリクエストを送り続け、プロキシがそのリクエストを異なるバックエンドへ適配します。

仕組み

3 層構造として理解できます。

フロントエンドは Claude Code
中間層は free-claude-code プロキシ
バックエンドは OpenRouter、DeepSeek、ローカルモデル、または他のモデルサービス

Claude Code は、自分が Anthropic-compatible API にアクセスしていると考えます。

プロキシはリクエストを受け取り、設定に応じて target provider を選び、必要なフィールドを変換し、応答を Claude Code に返します。

この構造の利点は、Claude Code 自体を変更する必要がなく、すべてのモデルサービスが Claude Code をネイティブにサポートする必要もないことです。プロキシがインターフェースを合わせられれば、より多くのモデルを同じワークフローへ接続できます。

対応バックエンド

README に挙げられている方向は次のとおりです。

NVIDIA NIM
OpenRouter
DeepSeek
LM Studio
llama.cpp
Ollama

これらのバックエンドは、異なる利用スタイルを表しています。

OpenRouter はモデル集約入口に近く、さまざまな商用モデルやオープンソースモデルを試せます。

DeepSeek は、中国語能力、コード能力、コストを重視する人に向いています。

LM Studio、llama.cpp、Ollama はローカルモデル寄りです。自分のマシンや社内環境でモデルを動かし、外部 API 依存を減らし、オフライン実験をしやすくします。

NVIDIA NIM は、企業や GPU 推論デプロイの場面により向いています。

なぜ Anthropic-compatible proxy なのか

Claude Code はもともと Anthropic のインターフェースとモデル習慣を前提に設計されています。

他のモデルへ接続しようとすると、最初に問題になるのはインターフェースの違いです。

リクエストフィールドが違う
モデル名が違う
streaming 形式が違う
tool use の表現が違う
エラー応答形式が違う
token とコンテキスト制限が違う

プロキシ層の価値はここにあります。

Claude Code 側から見えるインターフェースを Anthropic に近い形に保ち、バックエンド側で適配します。ユーザーにとっては、一度プロキシを設定すれば、同じ Claude Code ワークフローの中で異なるモデルを試せます。

向いている場面

free-claude-code は次のような場面に向いています。

Claude Code のターミナルワークフローを使いたい
非 Anthropic モデルを Claude Code 内で試したい
モデル呼び出しコストを下げたい
Claude Code を OpenRouter に接続したい
DeepSeek などの互換モデルサービスに接続したい
Ollama、LM Studio、llama.cpp でローカルモデルを使いたい
チーム用に統一されたモデルプロキシ入口を用意したい

公式 Claude Code を普通に使っていて、モデル提供者、コスト、ローカルデプロイに特別な要求がないなら、この種のプロキシは必須ではありません。

しかし、頻繁にモデルを比較したり、Claude Code をローカルやサードパーティーモデルへ接続したいなら、この種のツールは便利です。

OpenRouter や Ollama を直接使う場合との違い

OpenRouter、Ollama、LM Studio を直接使う場合、通常はモデルとチャットするか、API 経由でモデルを呼び出します。

free-claude-code の目的はそれらのサービスを置き換えることではなく、Claude Code という開発ワークフローへ接続することです。

違いは次の点にあります。

Claude Code のターミナル体験をそのまま使える
AI がコードリポジトリを中心にタスクを実行できる
モデルバックエンドを別 provider に切り替えられる
ローカルモデルも Claude Code ワークフローへ入れられる
設定がプロキシ層に集中し、各ツールを個別に変えなくてよい

つまり、新しいチャットクライアントではなくブリッジに近いものです。

ローカルモデルで注意すべきこと

Claude Code をローカルモデルへ接続するのは魅力的ですが、現実的な制限もあります。

第一に、モデル能力の差です。

Claude Code のタスクは単なるチャットではありません。コード理解、変更計画、ファイル編集、コマンド出力処理を含みます。ローカルの小さなモデルがこれらを安定してこなせるとは限りません。

第二に、コンテキストウィンドウです。

コードタスクはコンテキストを多く使います。モデルのコンテキストが小さいと、ファイルを読み切れない、制約を見落とす、多段階タスクで背景を失う、といった問題が起きます。

第三に、tool use の互換性です。

Claude Code ワークフローはツール呼び出しと構造化動作に依存します。バックエンドモデルがチャットできても、ツール呼び出しプロトコルに従うのが得意とは限りません。

第四に、速度とハードウェアです。

ローカルモデルの速度はマシン構成、量子化方式、モデルサイズに依存します。コードタスクで応答が遅すぎると、体験は大きく下がります。

そのため、ローカルモデルは実験、低リスクタスク、特定場面に向いています。複雑なコードタスクでは、モデル能力を見て慎重に選ぶ必要があります。

利用上の境界

この種のプロジェクトはタイトルで誤解されやすいので、境界を明確にしておく必要があります。

第一に、これは公式 Claude Code の無料枠ではありません。

Claude Code のリクエストを他のモデルバックエンドへ転送するだけです。OpenRouter、DeepSeek、NVIDIA NIM、その他 API を使う場合は、それぞれの価格、クォータ、利用規約に従う必要があります。

第二に、認可を回避するためのツールではありません。

どのプロキシツールを使う場合でも、Claude Code、モデル提供者、プロジェクト自体のライセンスや利用規約を守るべきです。公式制限を回避する手段として理解しないでください。

第三に、プロキシはリクエスト内容を処理します。

コード、コマンド出力、プロジェクトコンテキストがプロキシとバックエンドサービスを通る可能性があります。デプロイ時にはログ、キー、ネットワーク、プライバシー境界を考える必要があります。会社コードや機密プロジェクトでは、制御された環境を使うべきです。

第四に、モデルごとの挙動差は大きいです。

同じ Claude Code 操作でも、モデルを替えるとまったく異なる動作になることがあります。すべてのモデルが Claude を置き換えられると考えない方がよいです。

LiteLLM などのプロキシとの関係

考え方として、free-claude-code は「互換インターフェースプロキシ」に属します。

この種のツールの共通目標は、上位アプリケーションと下位モデルサービスの結合を減らすことです。上位アプリケーションは比較的統一されたインターフェースだけを見ればよく、下位 provider は設定で切り替えられます。

プロジェクトによって重点は異なります。汎用モデルゲートウェイ寄りのものもあれば、OpenAI-compatible API 寄りのものもあり、Claude Code のようなツール向けに特化しているものもあります。

free-claude-code が注目に値するのは、汎用チャットプロキシではなく、Claude Code を直接ターゲットにしている点です。

向いているユーザー

ある程度自分で調整できるユーザーに向いています。

Claude Code に慣れている
API key と model provider の設定方法を知っている
プロキシサービスの起動と環境変数を理解できる
ネットワーク、ポート、モデル名、streaming 問題を調査できる
コードタスクで異なるモデルの挙動を比較したい

開箱即用だけを求めるなら、公式設定の方がたいてい簡単です。

プロキシを立て、モデルを切り替え、パラメータを調整し、Claude Code をより多くのモデル環境へ接続したいなら、このプロジェクトは研究する価値があります。

参考

Alishahryar1/free-claude-code

最後に

free-claude-code の価値は「free」という言葉ではなく、Claude Code とより多くのモデルバックエンドの間に橋を架けることです。

Claude Code の開発体験を保ちながら、OpenRouter、DeepSeek、ローカルモデル、企業向け推論サービスを試したいとき、このような Anthropic-compatible proxy は役に立ちます。

Compound Engineering Plugin：AI コーディングを計画、実行、レビューの工程ループにする

Fri, 01 May 2026 03:15:39 +0800

Compound Engineering Plugin は、Every Inc が公開している AI コーディングワークフロープラグインです。

注目しているのは「AI により速くコードを書かせること」ではありません。AI コーディングを、よりエンジニアリングチームに近いループへ入れることです。まず計画し、次に実装し、その後レビューし、最後に経験を蓄積します。Claude Code、Codex、Cursor、Copilot のようなツールをよく使う人にとって、この種のプラグインはプロンプト問題ではなくワークフロー問題を解決します。

AI コーディングツールは強力になっていますが、実プロジェクトで難しいのはコード生成そのものではありません。AI に継続してプロジェクトルールを守らせ、タスク境界を理解させ、同じ間違いを繰り返させず、複数回の反復でコンテキストを蓄積させることです。

解決する問題

多くの人は AI コーディングアシスタントを次のような流れで使います。

要件を直接説明する
AI にコードを変更させる
結果が動くか確認する
エラーが出たら追加説明する
次のタスクでまた背景を最初から説明する

小さなタスクならこれで十分なこともあります。しかし複雑なプロジェクトでは問題が起こりやすくなります。

要件を整理しないまま AI が編集を始める
コード変更後に体系的な review がない
プロジェクト規約がユーザーの繰り返しの注意に依存する
同じ種類のミスが次回も起こる
複数の Agent ツール間で統一した作業方法がない
経験が再利用可能なルールとして蓄積されない

Compound Engineering Plugin が解決したいのは、この種の問題です。AI コーディングを複数の段階に分け、Agent を単なるコマンド実行者ではなく、より完全なエンジニアリングプロセスの参加者にします。

Compound Engineering とは何か

プロジェクト README の説明から見ると、Compound Engineering は AI 支援ソフトウェア開発の方法と理解できます。

重視するのは次のループです。

計画：目的を理解し、タスクを分解し、方針を確認する
実行：計画に沿ってコードを変更し、コマンドを実行し、問題を処理する
レビュー：実装品質、リスク、テストカバレッジを確認する
学習：経験を後続で再利用できるルールとして蓄積する

このループは実際のエンジニアリングチームの働き方に近いです。

信頼できるエンジニアは、要件を受け取ってすぐに無秩序に変更することはありません。変更後に何も確認せず渡すこともありません。まず影響範囲を判断し、実装し、リスクとテスト結果を確認し、最後に踏んだ落とし穴を記録します。AI Agent にも同じような制約が必要です。

なぜプラグインが必要なのか

プロンプトで AI に「先に計画してから実行してください」と伝えることはできます。しかしプロンプト自体は必ずしも安定しません。

会話が長くなり、コンテキストが複雑になると、モデルは計画を飛ばしたり、ルールを無視したり、タスク完了を急いで過度に自信を持ったりします。プラグインの価値は、ワークフローを固定し、異なる Agent 環境でも似た方法を守れるようにすることです。

この種のプラグインは通常、ワークフローをコマンド、ルール、テンプレート、サブフローに分解します。ユーザーは毎回完全なプロンプトを書く必要がなく、固定された入口から特定の段階を起動します。

たとえば：

まず Agent に計画を生成させる
計画に沿って段階的に実装する
変更後に review を起動する
問題が見つかったら修正に戻る
残す価値のある経験を記憶やルールに書く

これにより AI コーディングは、一回限りのチャットではなく「制御された協作」に近づきます。

対応する Agent 環境

README では、複数の AI コーディング環境をサポートすると説明されています。

Claude Code
Codex
Cursor
GitHub Copilot
Amp
Factory
Qwen Code

これは注目すべき点です。

多くのワークフローツールは 1 つのクライアントにだけ結びついており、ツールを替えるとルールを再利用できません。Compound Engineering Plugin は、クロス Agent のエンジニアリング方法に近く、計画、実行、レビューのような流れを異なるツールへ持ち込みます。

複数の AI コーディングアシスタントを同時に使うなら、このような統一ワークフローには価値があります。ツールごとに能力は違っても、プロジェクト規約、レビュー習慣、タスク分解方法はできるだけ一貫している方がよいです。

計画段階の役割

計画段階の価値は、AI が早すぎる段階で手を動かすのを防ぐことです。

複雑なタスクで本当に重要なのは、たいてい次のような問いです。

どのファイルを変更するのか
どのモジュールが影響を受ける可能性があるか
既存のパターンは何か
テストはあるか
リスクはどこにあるか
先に読むべきドキュメントはあるか
より小さなステップに分解できるか

Agent がこれらを考える前にコードを書き始めると、完成しているように見えてもプロジェクト構造から外れた実装になりやすくなります。

計画は長い必要はありません。良い計画は短く、具体的で、実行可能です。目的はドキュメントを増やすことではなく、後続の実装に境界を与えることです。

実行段階で避けるべきこと

AI がコードタスクを実行するとき、よく起こる問題があります。

関係ないコードをついでにリファクタリングする
ユーザーの既存変更を上書きする
happy path だけを処理する
エラーハンドリングを無視する
既存のプロジェクトスタイルに従わない
必要な検証を実行しない
エラー後に場当たり的に試す

ワークフロープラグインはこれらの問題を完全には消せませんが、ルールと段階制約によって発生確率を下げられます。

たとえば、実行段階では Agent に計画どおり段階的に進めさせます。計画範囲外の発見があった場合は、まずリスクを説明します。共有モジュールを変更する場合は、テストを追加するか、少なくとも関連検証を実行します。

この制約は大規模コードベースで特に重要です。AI が速くコードを書くほど、その勢いを制限するプロセスが必要になります。

レビュー段階が重要な理由

多くの AI コーディング失敗は、コードがまったく動かないからではありません。細部に問題があるからです。

境界条件が処理されていない
状態更新が一貫していない
API 契約がこっそり変わっている
テストが重要経路をカバーしていない
エラーメッセージが分かりにくい
性能やセキュリティリスクが触れられていない

レビュー段階は Agent を「作者モード」から「レビューモード」へ切り替えます。

作者モードでは自分の実装を正当化しがちです。レビューモードでは、穴、回帰リスク、テスト漏れを積極的に探すべきです。この 2 つの段階を分ける方が、同じ回答内で実装と自己レビューを同時に行わせるより信頼しやすくなります。

ユーザーにとっても、レビュー出力は価値があります。その変更をマージしてよいか、まだ修正が必要かを素早く判断できます。

学習と記憶の意味

プロジェクト名の “Compound” は、重要な考え方を示しています。エンジニアリング経験は複利的に増えるべきだ、ということです。

AI が毎回のミスをその場で直すだけで、次回また同じミスをするなら、生産性向上は限られます。より良い方法は、価値ある経験を蓄積することです。

このプロジェクトのディレクトリ規約
ある種類のエラーの調査方法
テストコマンドと注意事項
触ってはいけない生成ファイル
コードスタイルの好み
よく使う実装パターン

これらの経験は、ルール、記憶、ドキュメント、テンプレートになります。後続タスクでは、Agent がまずそれらの蓄積を読み、その後作業を始めます。

これが AI コーディングを「一回限りの問答」から「長期協作」へ進める鍵です。

向いている場面

Compound Engineering Plugin は次のような場面に向いています。

AI Agent を長期的に使ってコードを書く
1 つのプロジェクトを何度も、複数回にわたって変更する
AI に先に計画してから実装してほしい
変更後に review 思考へ自動で入ってほしい
チームで AI コーディングフローを統一したい
Claude Code、Codex、Cursor など複数ツールを同時に使う
プロジェクト経験を再利用可能なルールにしたい

たまに小さなスクリプトを AI に書かせるだけなら、完全なフローは重く感じるかもしれません。

しかし AI コーディングアシスタントを日常開発の相棒として使うなら、計画、実行、レビュー、学習のループは明らかに役立ちます。

通常のプロンプトテンプレートとの違い

通常のプロンプトテンプレートは、「タスクをどう明確に伝えるか」を解決します。

たとえば：

一歩ずつ考えてください
先にファイルを読んでください
コードスタイルを揃えてください
テストを実行してください
変更内容を要約してください

これらのプロンプトはもちろん有用です。しかし、毎回ユーザーが正しく使うことに依存しています。

Compound Engineering Plugin は、よりワークフロー層にあります。これらの要求を再現可能なプロセスとして整理し、異なる Agent ツールに適用します。毎回ゼロからプロンプトを書くのではなく、一つのフローの中でタスクを進めます。

簡単に言えば、プロンプトテンプレートはリマインダーであり、ワークフロープラグインは制度に近いものです。

利用時の注意

第一に、フローを負担にしないことです。

小さなタスクに完全な計画と長いレビューが常に必要なわけではありません。良いワークフローはタスクの複雑さに応じて調整できます。単純な問題は素早く処理し、複雑な問題では完全なループを使います。

第二に、レビューはテストの代わりにはなりません。

Agent review は多くの問題を見つけられますが、実行時エラーを見逃すことがあります。最終判断には、テスト、型チェック、ビルド結果、人間のレビューが必要です。

第三に、ルールは継続的に整理することです。

経験の蓄積は重要ですが、ルールが増えすぎるとノイズになります。古いルール、重複ルール、一回のタスクにしか合わなかった一時的な経験は、定期的に整理すべきです。

第四に、ツール間で一貫していることは完全に同じであることではありません。

Claude Code、Codex、Cursor、Copilot などは能力や対話方式が異なります。統一すべきなのは作業方法であり、すべてのコマンドや設定詳細が同じである必要はありません。

向いているチーム

チームがすでに AI Agent に実コードの変更を許可しているなら、「どのモデルが強いか」だけを議論しても不十分です。

より重要なのは次の点です。

AI は変更前にタスクを理解しているか
AI は変更中にプロジェクト境界を守っているか
AI は変更後にリスクを自発的にレビューしているか
AI は過去のミスから学べるか
チームに統一された Agent 利用規約があるか

Compound Engineering Plugin のようなプロジェクトの意味はここにあります。AI コーディングを個人の小技から、チームで再利用できるプロセスへ一歩進めます。

参考

EveryInc/compound-engineering-plugin

最後に

Compound Engineering Plugin が注目に値する理由は、AI コーディングコマンドを一つ増やすことではありません。AI コーディングを、継続的に改善できるエンジニアリングフローとして整理することです。

AI Agent が実プロジェクトに参加し始めると、計画、実行、レビュー、経験の蓄積は、一回限りのコード生成より重要になります。

Claude Code Hooks Mastery：13 個の Hooks ライフサイクルと自動化制御の入門

Fri, 01 May 2026 03:11:27 +0800

claude-code-hooks-mastery は、Claude Code Hooks を学ぶためのプロジェクトです。

単にいくつかのスクリプトを並べただけではありません。Claude Code の hooks ライフサイクル、設定方法、スクリプトの書き方、よくある自動化シナリオをまとめて説明しています。Claude Code をより制御しやすく、よりエンジニアリング向けの助手として使いたい人にとって、読む価値のある資料です。

Claude Code は標準でもコードを読み、ファイルを編集し、コマンドを実行できます。しかし、特定のタイミングで権限を確認したり、危険な操作を止めたり、プロジェクト規約を注入したり、テストを実行したり、チームルールを思い出させたりしたい場合、チャット指示だけでは安定しません。Hooks の価値は、「毎回 AI に思い出させたいルール」を実行可能なワークフローに変えることです。

Hooks が解決する問題

Claude Code をしばらく使うと、よく次のような課題が出てきます。

新しい会話のたびに同じプロジェクトルールを説明する必要がある
実行してはいけないコマンドを実行しないか不安
ファイル変更の前後で自動チェックしたい
コミット前にフォーマット、テスト、セキュリティスキャンを走らせたい
チーム規約を口頭の注意ではなく固定フローにしたい
ツール呼び出しの前後でコンテキストを取得し、ログやブロックに使いたい
複雑なタスクでサブエージェントや専用スクリプトを起動したい

Hooks は、こうした「決まったタイミングでの自動動作」のためにあります。

Claude Code ワークフロー内のイベントフックとして考えるとわかりやすいです。セッション開始、ユーザーのプロンプト送信、モデルがツールを呼び出す直前、ツール呼び出し完了、エージェント終了直前などのタイミングで、設定したスクリプトを実行できます。

13 個の Hooks ライフサイクル

このプロジェクト README の重要な点の一つは、Claude Code の 13 個の hook イベントを体系的に整理していることです。

これらのイベントは、セッション開始からツール呼び出し、ユーザー入力からエージェント終了まで、複数の段階をカバーします。用途別には、おおまかに次のように分けられます。

セッション起動関連：環境初期化、プロジェクトコンテキスト注入
ユーザー入力関連：プロンプト確認、ルール補足、監査
ツール呼び出し前関連：権限判断、コマンドブロック、安全チェック
ツール呼び出し後関連：結果記録、フォーマット起動、検証実行
タスク終了関連：要約、クリーンアップ、通知、状態保存

このライフサイクル設計により、すべてのルールを長いプロンプトに詰め込む必要がなくなります。

たとえば、権限制御はツール呼び出し前に行うべきです。フォーマットチェックはファイル変更後の方が自然です。プロジェクト規約の注入は、セッション開始時やユーザー入力後が向いています。正しい hook ポイントにルールを置く方が、すべてを system prompt に詰めるより信頼しやすくなります。

設定ファイルの場所

Claude Code の hooks は通常、設定ファイルで構成します。

よく使われる場所は次のとおりです。

ユーザー単位の設定：~/.claude/settings.json
プロジェクト単位の設定：.claude/settings.json

ユーザー単位の設定は、一般的な安全ルール、コマンドブロック、ログパスなど、個人の好みに向いています。

プロジェクト単位の設定は、そのリポジトリに関するルールに向いています。たとえば、必ず実行するテスト、編集禁止のディレクトリ、生成ファイルの扱い、コミット前のチェックなどです。

チームで Claude Code を使うなら、プロジェクト単位の設定をリポジトリに置くのがおすすめです。そうすれば、各自が記憶で AI に注意するのではなく、全員が同じ AI 協作制約を持ってプロジェクトを開けます。

単一ファイルスクリプトが重要な理由

このプロジェクトでは UV の単一ファイルスクリプトが強調されています。

利点はデプロイが簡単なことです。1 つの Python ファイルで依存関係を宣言して実行できるため、1 つの hook のために複雑な環境を維持する必要がありません。多くの hook は小さな処理を 1 つ行うだけなので、この形式は適しています。

コマンドの実行可否を確認する
ファイルパスが安全か判断する
プロジェクト規約を読み、Claude に返す
出力に機密情報が含まれていないか調べる
変更後にフォーマットやテストを実行する
イベントをログに書く

Hook スクリプトは小さいほど保守しやすく、新しい複雑なシステムになりにくくなります。

どんな自動化ができるか

claude-code-hooks-mastery は多くの方向性を示しています。実務でよく使うのは次のようなものです。

1. 権限と安全制御

これは hooks の最も直接的な用途です。

Claude Code がコマンドを実行する前に、その内容をチェックできます。削除、リセット、クリア、上書きなどの高リスク操作が含まれている場合、実行を止めるか、人間の確認を求められます。

同様のルールはファイルパスにも使えます。

本番設定を変更しない
秘密鍵ファイルに書き込まない
マイグレーションスクリプトを削除しない
指定ディレクトリに触れない
未承認のネットワークコマンドを実行しない

この保護をツール呼び出し前に置く方が、「危険な操作をしないで」とプロンプトに書くより確実です。

2. コンテキスト注入

多くのプロジェクトには固定された背景があります。

技術スタック
コーディング規約
テストコマンド
ブランチ戦略
ディレクトリ構造
禁止事項
生成ファイルの扱い

これらを毎回手動で Claude Code に伝えるのは面倒で、漏れやすいです。Hooks を使えば、セッション開始時やユーザーのプロンプト送信後に必要なコンテキストを自動注入できます。

これは Claude Code にプロジェクト単位の作業マニュアルを渡すようなものです。README や開発ドキュメントを置き換えるものではありませんが、AI がタスクを始める前に正しい状態へ入りやすくなります。

3. 変更後の検証

Claude Code がファイルを変更した後、hook で自動チェックを起動できます。

よくある処理は次のとおりです。

フォーマットを実行する
lint を実行する
単体テストを実行する
型エラーを確認する
生成ファイルをスキャンする
Markdown や JSON の形式を検証する

これは低レベルなミスを減らすのに役立ちます。AI が複数ファイルを変更した場合、変更後に軽量な検証を走らせることで、問題を早めに見つけられます。

ただし、hook に重い処理をデフォルトで入れるのは向きません。ファイル変更のたびに完全なテストスイートを走らせると、体験が遅くなります。より実用的なのは、ファイル種別、ディレクトリ、タスクのリスクに応じてチェック範囲を選ぶことです。

4. チームルールの検証

チームに明確な約束があるなら、その一部を hooks に入れられます。

たとえば：

コミットメッセージ形式
コードスタイルルール
特定の生成ファイルを直接変更しない
ドキュメントを同時に更新する
API 変更ではテストも更新する
特定ディレクトリは指定ツールでのみ生成する

これにより Claude Code は、制約のない外部アシスタントではなく、チームワークフローの一部に近づきます。

もちろん、hooks は CI の代わりではありません。ローカルでの早めの注意や前置ブロックに向いています。最終検証は CI、review、テストシステムに任せるべきです。

5. サブエージェントと専用タスク

README ではサブエージェント関連の内容にも触れています。

この使い方は、複雑なタスクをより専門的なフローに分ける場合に向いています。たとえばメイン会話が要求を理解し、hook や設定が専用のチェック、監査、要約、ドキュメント整理タスクを起動します。

個人ユーザーにとって、最初にやる価値があるのは複雑なエージェント編成ではありません。まずは反復的で明確かつ低リスクな処理を hooks に任せることです。ルールが安定してから、より複雑な自動化を検討すれば十分です。

Statusline と出力スタイル

プロジェクトは statusline と出力スタイルも扱っています。

一見すると体験面の細部ですが、Claude Code を長期的に使う場合には重要です。Statusline は現在のコンテキスト、タスク状態、環境情報、ヒントを表示できます。出力スタイルは Claude Code の回答を自分の作業習慣に合わせやすくします。

毎日同じターミナルで AI と協作するなら、こうした細部は効率に影響します。良い状態表示は誤操作を減らし、現在の会話が正しいプロジェクト、正しいブランチ、正しい環境にいるかを素早く判断できます。

hooks を重くしすぎない

Hooks は強力ですが、何でも詰め込む場所ではありません。

良いルールは次のとおりです。

高頻度の処理は速くする
安全ブロックは明確にする
出力は短くする
失敗理由は読みやすくする
スクリプトはできるだけ単一責務にする
重いチェックは明示コマンドや CI に任せる

毎回 10 秒以上かかる hook は、すぐに無効化したくなります。ブロックルールが曖昧な hook も、Claude Code とユーザーの両方にとって次に何をすべきか分かりにくくなります。

Hooks は、境界が明確な処理に最も向いています。許可または拒否、コンテキスト追加、ログ記録、軽量チェック、次の手順提示などです。

向いているユーザー

たまに Claude Code に小さなコード変更を頼むだけなら、hooks を深く学ぶ必要はまだないかもしれません。

しかし、次のような場合はこのプロジェクトを調べる価値があります。

Claude Code を頻繁に使う
AI に実際のプロジェクトコードをよく変更させる
AI が危険なコマンドを実行しないか不安
チーム規約を AI ワークフローに自動注入したい
変更後に自動チェックを走らせたい
繰り返しの注意を設定に変えたい
より安定した AI コーディングフローを作っている

特に複数人で作業するプロジェクトでは、hooks の意味が大きくなります。チーム経験の一部をスクリプトとして残せるため、各メンバーがその場で AI に注意する必要が減ります。

利用時の注意

第一に、安全系 hook から始めることです。

複雑な自動化よりも、コマンドブロック、パス保護、機密ファイルチェックの方が実装しやすく、すぐにリスクを下げられます。

第二に、プロジェクト単位のルールは慎重にコミットすることです。

.claude/settings.json は、そのリポジトリを使う全員に影響します。コミット前に、通常開発を過度に制限しないこと、自分のマシンにしかないパスに依存しないことを確認した方がよいです。

第三に、hook の出力は簡潔にすることです。

Claude Code はその出力を消費します。長すぎるとコンテキストを汚し、曖昧すぎると次の行動を導けません。必要な判断と次の提案だけを返すのがよいです。

第四に、デバッグしやすく保つことです。

Hooks が増えると、問題は設定、スクリプト、権限、パス、依存関係、Claude Code 本体のどこからでも起こり得ます。明確なログを残すと、後の調査がずっと楽になります。

参考

disler/claude-code-hooks-mastery

最後に

Claude Code Hooks の価値は、「AI に毎回覚えていてほしいルール」を、実際に実行されるフローへ変えることです。

すでに Claude Code を実プロジェクトで使い始めているなら、hooks は「会話できるコーディング助手」から「制約を持つエンジニアリング協作者」へ進むための重要な一歩です。

Claude-Mem：Claude Code にセッションをまたぐ長期記憶を追加する

Fri, 01 May 2026 03:01:02 +0800

Claude-Mem は、Claude Code 向けの永続的な記憶システムです。

解決しようとしている問題は明確です。AI コーディングアシスタントは、新しいセッションを始めるたびに、以前話したアーキテクチャ判断、踏んだ落とし穴、プロジェクトの好み、実装背景を忘れがちです。
長く続くプロジェクトでは、毎回同じ文脈を説明し直すのはかなり無駄です。

Claude-Mem の考え方は、Claude Code の会話内容を記憶として圧縮し、ローカルデータベースとベクトルストアに保存し、あとから検索ツールで取り戻すというものです。

何を解決するのか

Claude Code はコードタスクに強いですが、セッションの文脈には限界があります。

よくある課題は次の通りです。

新しいセッションが過去の作業を知らない
プロジェクトの設計判断を何度も説明する必要がある
以前調査した問題を再び踏みやすい
長期タスクに連続した記憶がない
複数の会話にまたがるプロジェクト知識を蓄積しにくい

Claude-Mem はこれらの問題を中心に設計されています。

単にチャットログを保存するのではありません。会話を検索しやすい記憶断片に圧縮します。後で必要になったとき、意味検索で関連する文脈を取り戻せます。

仕組み

README の設計を見ると、Claude-Mem は主にいくつかの部分で構成されています。

第一の部分は hooks です。

Claude Code の会話フローに接続し、適切なタイミングで会話データを捕捉します。

第二の部分はバックグラウンド worker です。

worker は原始的な会話内容を、より短く、検索しやすい記憶へ処理します。

第三の部分はローカルストレージです。

プロジェクトは構造化メタデータの保存に SQLite を使い、ベクトルインデックスには Chroma を使います。これにより、会話記録の基本情報を保ちながら、意味検索にも対応できます。

第四の部分は mem-search です。

これは Claude Code が使う検索入口です。過去の文脈が必要なとき、関連する記憶を検索できます。

全体の流れは次のように理解できます。

Claude Code のセッションで内容が生まれる
hooks が会話データを捕捉する
worker が非同期に圧縮・整理する
記憶を SQLite と Chroma に書き込む
後のセッションで mem-search によって検索する

どんな場面に向いているか

Claude-Mem は長期プロジェクト向けで、一回きりの小さなタスク向けではありません。

たとえば：

ひとつのリポジトリを何日も開発し続ける
コード構造が複雑で、背景説明が多い
プロジェクト規約、命名習慣、アーキテクチャ選択を覚えてほしい
Claude Code に頻繁にバグ修正、機能追加、文書整理を任せる
AI に「以前なぜこう変更したのか」を覚えてほしい

Claude Code に一行だけ直してもらう程度なら、長期記憶の意味は大きくありません。
しかし Claude Code を長期的な協力者として使うなら、これは役に立ちます。

インストールと起動

README では、インストール方法は直接的です。

1
2

npm install -g claude-mem
claude-mem install

起動には次を使います。

`1`	`claude-mem start`

状態確認：

`1`	`claude-mem status`

停止したい場合：

`1`	`claude-mem stop`

これらのコマンドの目的は、記憶システムを長く動くローカルサービスとして Claude Code のワークフローに接続することです。

`mem-search` の使い方

mem-search は記憶を取り戻すための重要な入口です。

普通の検索を置き換えるものではなく、Claude Code が過去の会話内容を意味で検索できるようにするものです。

たとえば Claude Code に次のようなことを検索させられます。

あるモジュールがなぜそのように設計されたのか
ある Bug を当時どう調査したのか
プロジェクトで合意した命名規則
以前議論した技術的な取捨選択
あるリファクタリングの背景

これは単純なキーワード検索とは違います。
記憶圧縮とベクトルインデックスがうまく機能すれば、正確な言い回しを覚えていなくても、意味的に近い内容を取り戻せます。

普通のプロジェクト文書との違い

プロジェクト文書は、安定した結論を記録するのに向いています。

たとえば：

アーキテクチャ説明
デプロイ手順
API 規約
データベース構造
開発ルール

Claude-Mem は、会話過程で生まれる文脈を記録するのに向いています。

たとえば：

なぜある案が却下されたのか
一時的な問題をどう回避したのか
実装の背後にあった議論
まだ文書化されていないプロジェクトの好み
複数の会話で積み重なったタスク背景

両者は互いの代替ではありません。
安定した知識はプロジェクト文書へ書き、過程的な文脈は記憶システムで検索できるようにするのがよいです。

使うときの注意点

第一に、長期記憶は多ければよいわけではありません。

すべての会話を区別なく保存すると、後の検索がノイズだらけになる可能性があります。価値が高いのは、プロジェクト判断、実装背景、問題調査、長期的な好みです。

第二に、記憶はコードや文書の代わりにはなりません。

AI が見つけた古い文脈は参考にすぎません。最終判断は現在のコード、テスト結果、最新の要求に基づくべきです。

第三に、プライバシーとローカルデータに注意が必要です。

会話内容を保存する以上、どのプロジェクトに接続してよいか、どの機密情報を会話に入れるべきでないかを理解しておく必要があります。

第四に、記憶システムにはメンテナンスが必要です。

プロジェクトが進むにつれて、古い記憶は古くなる可能性があります。古い文脈が誤って使われると、後続タスクを誤導することがあります。

この種のツールが注目に値する理由

AI コーディングツールは、「一回限りの質問応答」から「長期的な協力」へ向かっています。

一回限りの質問応答では、モデルは現在の質問に答えれば十分です。
長期的な協力では、プロジェクト履歴、過去の判断、チームの好み、すでに踏んだ落とし穴を知っている必要があります。

Claude-Mem のようなツールの意味はここにあります。「文脈を覚える」ことを、一時的なチャット能力ではなく、インストールし、実行し、検索できるローカルシステムにします。

実際のエンジニアリングプロジェクトでは、単にモデルのコンテキストウィンドウを長くするより実用的です。
多くの情報は一度に文脈へ詰め込めばよいのではなく、必要なタイミングで取り戻せることが重要だからです。

誰が試すべきか

次のような場合は試す価値があります。

Claude Code を高頻度で使っている
同じプロジェクトを日をまたいで扱うことが多い
プロジェクト文脈が複雑
AI に同じ背景を何度も説明している
会話内の経験を蓄積したい

Claude Code をたまに使うだけ、またはプロジェクトが小さい場合は、まだ必要ないかもしれません。

参考

thedotmack/claude-mem

最後に

Claude-Mem の重点は「チャットログを保存すること」ではなく、Claude Code が後続タスクで有用な文脈を取り戻せるようにすることです。

AI コーディングが一回限りのタスクから長期プロジェクト協力へ移るにつれ、記憶システムはますます重要になります。
文書やテストを置き換えるものではありませんが、繰り返し説明を減らし、AI をプロジェクト履歴を理解した助手に近づけます。

Ralph とマルチエージェント協調：AI を長時間安定して働かせるには

Mon, 27 Apr 2026 08:19:02 +0800

最近 coding agent を使っていると、すぐにひとつの現実的な問題にぶつかります。AI は確かに仕事をしてくれる。でも、どうすれば何時間も動かし続けても途中で脱線せず、要件を忘れず、同じ作業をやり直さずに済むのか。

Ralph やマルチエージェント協調をめぐる議論で本当に重要なのも、まさにこの点です。単にどのモデルが強いかを比べる話ではありません。より実用的な問いは、長いタスクでも AI が安定して動けるように、どうワークフローを設計するか です。

この問題を分解すると、よく出てくるルートは大きく 2 つあります。

Ralph 方式：新しいセッションを繰り返し起動し、ファイルシステムで文脈をつなぐ
マルチエージェント方式：リード Agent が調整し、子 Agent が分担して実行する

もっと平たく言えば、問われているのは「どのモデルが強いか」ではなく、「どう AI を組織して、継続的に成果を出す小さなチームのように動かすか」です。

01 なぜ長時間タスクは崩れやすいのか

短いタスクでは、多くの問題は表に出ません。指示を 1 つ出し、モデルが数ファイルを読み、少しコードを書き換えれば終わります。

ところがタスクが長くなると、問題が一気に表面化します。

会話が伸び続けてコンテキストが膨らむ
初期の要件が新しい情報に押し流される
ひとつの Agent が設計、実装、テストまで全部抱える
明確な受け入れ確認がないと、「終わった」と「終わったと言っているだけ」が混ざる

そのため、長時間 AI を動かすときに本当に問われるのは単発の出力性能ではなく、タスク分割、状態の受け渡し、役割分担、フィードバックループ です。

02 Ralph 方式：長いタスクを短いラウンドに分ける

Ralph の考え方は、まず「コンテキストがどんどん汚れていく」問題を解くのに向いています。

やっていることはシンプルです。

ループで新しい agent セッションを何度も起動する
各ラウンドでは十分小さなタスクを 1 つだけ扱う
ラウンドをまたぐ状態は会話ではなくファイルに置く

利点は明快です。毎回 fresh context から始まるので、1 ラウンドごとの集中が保ちやすく、過去の履歴に引きずられにくくなります。

Ralph 系のプロジェクトを見たことがあるなら、構造はかなり一貫しています。

現在のタスクは構造化ファイルに書く
途中の学びは進捗ファイルに残す
コードの変化は git 履歴に残す

つまり Ralph は、1 つの Agent に「全部を永遠に覚えさせる」ことを目指していません。記憶を意図的に外へ逃がし、セッションそのものを軽く保とうとします。

この種の方式は、特に次のような条件で相性がいいです。

作業がすでに小さな story に分けられている
各 story が 1 つの context window に収まる
プロジェクトに tests、typecheck、その他のチェックがある

これは AI を一歩ずつ安定して前に進めるにはどうするか という問題への答えです。

03 マルチエージェント方式：1 人では抱えきれない仕事を分担する

もうひとつのルートがマルチエージェント協調です。

この種のワークフロー設計でより有望なのは、リード Agent が自分で全部やるのではなく、調整役に回り、ほかの Agent が実装、テスト、確認、受け入れを分担する形です。

ここが Ralph との大きな違いです。

Ralph は直列の反復に近い
マルチエージェントは並列の分業に近い

タスクの中に自然な役割分担があるなら、マルチエージェントのほうが扱いやすくなります。たとえば次のように分けられます。

ひとりがタスク分解と実行計画を担当する
ひとりが実装する
ひとりがテストして検証する
ひとりが結果が最初の要件に合っているか見直す

大事なのは、ただウィンドウを増やすことではありません。価値があるのは役割を分離することです。もともと 1 つの Agent に押し込んでいた仕事を、より明確な段階に分けられます。

役割の境界がはっきりすると、いくつかの問題が軽くなります。

書く人とレビューする人を分けられる
テストする側が毎回ゼロから要件を再構築しなくていい
リード Agent が実装詳細に埋もれにくい

これは AI を小さなチームのように協調させるにはどうするか という問題への答えです。

04 本当に重要なのは並列化ではなく、どう分けるか

Ralph を使うにしてもマルチエージェントを使うにしても、見落とされやすいのはこの点です。大事なのは Agent の数より、ワークフロー設計の質です。

タスク分解が悪ければ、Agent を増やしても混乱を並列化するだけです。

より安定しやすい分け方には、だいたい次の特徴があります。

1 タスクに 1 つの明確な目標がある
1 役割に 1 種類の出力責任がある
各ラウンドに明確な完了条件がある
前のラウンドの成果が次のラウンドでそのまま使える

たとえば「機能を全部作って」と一気に投げるより、次のように段階を切るほうが安定しやすいです。

まず要件と境界を分ける
次に実装を分ける
次にテストを分ける
最後に受け入れ確認を独立させる

この分け方の利点は、問題が起きたときに、理解、実装、テスト、受け入れ基準のどこに原因があるのか見つけやすいことです。

05 なぜ受け入れ確認が重要なのか

多くの AI ワークフローが崩れるのは、前半で何もしていないからではありません。最後に、本当に独立した確認ステップがないからです。

長いタスクでは、「結果が生成された」と「その結果が本当に使える」のあいだに、かなり大きな差があることがよくあります。

だからこそ、開発と受け入れを分けて考える方向が重要です。複雑な仕組みにしなくても、少なくとも次の問いは独立して投げる価値があります。

最初のタスクを本当に完了しているか
表面だけ直して根本原因を残していないか
テストが都合のいい経路だけを見ていないか
上流の要件を途中で勝手に変えていないか

この層が欠けると、AI は長いフローの中で何度でも「成功した」と自己申告しがちです。

06 どう選ぶべきか

手早い目安としては、次のように考えられます。

いちばん痛いのがコンテキスト肥大化や長セッションの失焦なら Ralph
いちばん痛いのが 1 つの Agent に役割を詰め込みすぎていることならマルチエージェント

もう少し具体的に言うと、

Ralph は、流れが明快で、粒度が細かく、ラウンド単位で進めやすい仕事に向く
マルチエージェントは、役割分担が明確で、並行処理や相互検証が必要な仕事に向く

実際には、この 2 つは対立するものではありません。むしろ成熟したやり方は組み合わせです。

外側は Ralph のような反復ループで大きなタスクを進める
内側は各ラウンドでマルチエージェントを使い、調査、実装、テスト、受け入れを分担する

こうすれば、長いコンテキストの制御と、1 ラウンド内の協調効率を両方取りにいけます。

07 ひとことでまとめると

これらの方法が重要なのは、Ralph やマルチエージェントそのものを単独で推しているからではありません。むしろ、ひとつの現実的な事実をはっきりさせているからです。AI を長時間安定して働かせる鍵は、モデル単体の強さよりも、コンテキスト、タスク、役割、受け入れ確認をどう設計したかにある。

すでに Claude Code、Codex、そのほかの coding agent に長めの実タスクを任せ始めているなら、こうしたワークフロー発想は「もっと強いモデルに替える」より優先して学ぶ価値があります。

Ralph とは何か：Claude Code と Amp を反復実行できる自律開発フローに変える方法

Mon, 27 Apr 2026 08:08:55 +0800

最近、coding agent の長時間ワークフローに注目しているなら、snarktank/ralph は一度見ておきたい小さなプロジェクトです。これは新しいモデルのラッパーでも、チャット UI をもう一枚かぶせたものでもありません。Claude Code や Amp を autonomous loop として組み立て、PRD にある story を 1 つずつ進め、すべて終わるまで回し続ける仕組みです。

核になる発想はかなりシンプルです。同じ agent を、どんどん長くて汚れていくコンテキストの中で無理に走らせ続けないこと。代わりに、各イテレーションごとに新しい AI coding session を立ち上げること。これによって、コンテキストの膨張を抑えつつ、タスク境界もはっきりします。

01 Ralph とは何か

Ralph の公式な位置づけは明快です。PRD の項目が完了するまで、AI coding tool を繰り返し実行する autonomous AI agent loop です。

現在のリポジトリでは、次の 2 つのツールに対応しています。

Amp CLI
Claude Code

各イテレーションでは fresh instance が起動されます。つまり、1 本の会話を延々と伸ばし続けるのではなく、次のような外部状態に記憶を持たせます。

git 履歴
progress.txt
prd.json

ここが重要です。大きなタスクを agent に長く走らせるときの問題は、モデルがコードを書けないことではない場合が多いです。むしろ、会話が重くなり、コンテキストを落とし、要件を忘れ、同じ作業を繰り返しやすくなることのほうが大きい。Ralph は、ほぼこの問題に正面から向き合って設計されています。

02 どう動くのか

Ralph のワークフローは 3 段階です。

1. まず PRD を作る

README では、まず付属の prd skill を使って要件書を作り、機能を小さめの story に分割することを勧めています。

2. PRD を `prd.json` に変換する

次に ralph skill を使って、Markdown の PRD を構造化された prd.json に変換します。このファイルには user stories と、それぞれが通過済みかどうかが記録されます。

3. ループスクリプトを実行する

実際の実行を担うのは ralph.sh です。コマンドはおおむね次の形です。

1
2

./scripts/ralph/ralph.sh [max_iterations]
./scripts/ralph/ralph.sh --tool claude [max_iterations]

デフォルトは 10 イテレーションです。各ラウンドではおおよそ次のことを行います。

branchName からブランチを作る
passes: false で最優先の story を選ぶ
その story だけを実装する
typecheck や tests などの品質チェックを走らせる
チェックを通過したらコミットする
prd.json を更新する
学びを progress.txt に追記する
次のラウンドへ進む

つまり Ralph は、すべてを一気に終わらせようとはしません。1 つのコンテキストウィンドウに収まる小さなループへと仕事を圧縮していくわけです。

03 Ralph の面白いところ

1. 毎回 fresh context を使う

これが Ralph のいちばん中心的な設計です。README でも、各イテレーションは新しい AI instance であり、イテレーション間の記憶は git、progress.txt、prd.json にしか残らないと強調されています。

これは、Claude Code などを 1 本の長い会話の中で使い続ける一般的なやり方とはかなり違います。後者はタスクが大きくなるほど履歴に引きずられて重くなり、少しずつ焦点を失いがちです。Ralph は、1 回の実行ですべてを覚えさせることを諦め、その代わりに記憶をファイルに逃がします。

2. タスクを小さく保つことを前提にしている

ドキュメントでは、各 PRD item は 1 つの context window で終えられる大きさでなければならないと明言されています。たとえば、フィルターを 1 つ追加する、server action を更新する、DB のカラムを 1 本足す、といった粒度は適切です。一方で、API 全体の再設計やダッシュボード全体の構築は大きすぎます。

この制約はとても現実的です。多くの autonomous agent loop が崩れる理由は、loop そのものではなく、タスク分割が粗すぎて 1 ラウンドに抱え込む量が多すぎることにあります。

3. コードだけでなく学びも残す

progress.txt だけでなく、README は AGENTS.md の更新も強く勧めています。理由は単純で、今後のイテレーションや将来の開発者がそのメモを読むからです。各ラウンドで見つかったパターン、注意点、慣習は、プロジェクト文書として残しておいたほうがいい。

言い換えると、Ralph は agent に継続してコードを書かせるだけでなく、コードベースに対する作業記憶も蓄積させようとしています。

04 どんな場面に向いているか

次のような条件なら、Ralph はかなり相性がいいです。

すでに明確な user stories に分解できている
テスト、typecheck、CI のような信頼できるフィードバックループがある
1 本の長い会話に全部を押し込まず、agent を継続的に前進させたい
一発完了より、反復で少しずつ進む形を受け入れられる

逆に、要件がまだ曖昧だったり、議論を何度も往復しながら方向を頻繁に変える必要がある作業では、Ralph は最初の選択肢ではないかもしれません。要件が固まり、実装を安定して前に進めたい段階のほうが向いています。

05 普通の Claude Code 利用と何が違うか

ふつうに Claude Code を使う場合は、1 つのセッションを開いて、そこからコードを読み、編集し、コマンドを実行し続ける形が一般的です。これは小規模から中規模の作業では非常に便利ですが、大きな作業になると次の 2 点が問題になりやすいです。

コンテキストが伸び続ける
途中の判断が構造化された形で残りにくい

Ralph は Claude Code や Amp を、より「バッチ実行器」に近いものへ変えます。

タスクの起点は都度の会話ではなく prd.json
各ラウンドが扱うのは 1 つの story だけ
完了状態はファイルへ書き戻される
学びは progress.txt に残る
コード変更は git に残る

その意味で、これは新しい AI assistant というより、coding agent の上にイテレーション制御を追加する仕組みと見たほうが近いです。

06 ひとつ重要な前提

Ralph がうまく機能するかどうかは、loop 自体よりもフィードバックループの質に左右されます。README もかなり率直で、typecheck、tests、CI がないと、エラーは後続イテレーションで積み重なっていくと書いています。

フロントエンド作業については、acceptance criteria にブラウザ検証を含めることまで勧めています。実際の確認がないと、agent は「見た目上は終わった」と「本当に動く」を簡単に混同してしまうからです。

ここは大事です。Ralph は magical automation ではありません。むしろ、すでに持っている開発の規律を増幅する仕組みに近いです。タスク分割が明快で、チェックがしっかりしているプロジェクトほど価値が出ますし、その土台がないなら、混乱を繰り返し増幅するだけになりかねません。

07 ひとことでまとめると

Ralph の価値は、大規模な新基盤を作ったことではありません。シンプルだけれど実用的な発想を、すぐ使えるフローに落とし込んだところにあります。Claude Code や Amp に各ラウンドで十分小さな story を 1 つだけ扱わせ、fresh context で集中させつつ、git、prd.json、progress.txt で継続性を保つ。

もし、すでに coding agent を実プロジェクトで使い始めていて、「長いタスクをどう安定して前に進めるか」で悩んでいるなら、Ralph のやり方はかなり参考になります。

参考リンク

GitHub リポジトリ: https://github.com/snarktank/ralph
インタラクティブなフローチャート: https://snarktank.github.io

Claude Code の環境設定4点セット：CLAUDE.md、Rules、Memory、Hooks をまとめて理解する

Thu, 23 Apr 2026 10:43:40 +0800

Claude Code をしばらく使っていると、すぐに気づくことがあります。モデルそのものが重要なのは当然ですが、どんな環境を与えるか、どんな境界を置くか、どんなルールを持たせるかも同じくらい重要だということです。

最初のうちは「今回の prompt をどう書くか」に意識が向きがちです。ですが、本当に Claude Code を使いこなすようになると、気になるのは別のことです。

それは自分が誰かを分かっているか
自分がどう働くかを分かっているか
破ってはいけないルールを分かっているか
先に確認すべきことを分かっているか
そうした境界を長期的に覚えていられるか

Claude Code が成熟したツールになる理由は、単にモデルが強いからではありません。こうした働き方を仕組みとして定着させる一式があるからです。大きく分けると、その中核は次の4層です。

CLAUDE.md
Rules
Memory
Hooks

この記事では、この4つをまとめて整理します。

なぜ単発のプロンプトより環境設定のほうが重要なのか

Claude Code を、雇ったアシスタントだと考えてみてください。

初日に「何か手伝って」と一言だけ伝えることはないはずです。普通は説明書を渡して、次のようなことを伝えます。

自分はどんな立場なのか
どんなコミュニケーションのトーンを好むのか
どんな操作は必ず事前確認が必要か
以前起きたどんなミスを今後は避けたいか
重要な文書がどこにあるか

だからこそ、長い目で見ると、環境設定は単発の prompt より重要になりやすいのです。

prompt が解決するのは「今回は何をするか」です。環境設定が解決するのは「これから毎回どう働くか」です。

第1層：`CLAUDE.md`

まず一番基本から始めます。CLAUDE.md は本質的にはただのテキストファイルです。

そこには Claude への説明を書けます。たとえば：

自分が誰か
何に取り組んでいるか
どんなコミュニケーションを好むか
守るべきルール
現在のプロジェクトの特殊事情
重要な文書やディレクトリの場所

Claude Code が起動するたびに、この文書は自動的にコンテキストに入るので、モデルは必ず目を通します。

私はこれを「共有された暗黙知のファイル」だと考えることが多いです。実際、それがあなたとモデルの長期協業における前提になるからです。

`CLAUDE.md` に書くのに向いていること

CLAUDE.md に最も向いているのは、おおむね次のような内容です。

身元や仕事上の背景
話し方や出力の好み
グローバルな行動ルール
よく参照する重要なプロジェクト背景
よくあるミスとその防ぎ方

たとえば：

自分のタイムゾーン
モデルによるメールやメッセージの直接送信を許可するか
どの操作が不可逆か
文書やファイルの扱い方の癖
セキュリティ方針や機密情報の境界

とても大事な原則：できるだけ簡潔にする

CLAUDE.md には非常に大事な原則があります。それは、できるだけ簡潔に保つことです。

理由は単純で、毎回コンテキストに強制的に入るからです。

長くなりすぎると、大量のコンテキストを消費してしまい、本当に重要な情報が薄まります。モデルが読まないのではなく、注意が分散し、最も重要なルールを取りこぼしやすくなるのです。

公式の目安としては、400 行を超えないほうがよいと言われることが多いです。

私自身はもう少し保守的で、できるだけ 200 行以内に収めるようにしています。

`CLAUDE.md` のよくあるスコープ

CLAUDE.md には実際には複数の配置レベルがあり、そのレベルによって効く範囲が変わります。最もよく使うのは次の2つです。

1. User Level

これはグローバルレベルです。

ローカル環境に置かれ、そのマシン上で扱うすべてのプロジェクトに効きます。

ここに向いているのは：

自分の基本情報
汎用的なコミュニケーションの好み
プロジェクトをまたいで通用する作業習慣
グローバルな安全ルール

たとえば、あなたのタイムゾーンが一般的に想定されがちなものではなく、バンコク時間であるなら、それは user level に置くのが自然です。そうすれば、後で日時を扱うときのミスが減ります。

2. Project Level

こちらはプロジェクトレベルです。

特定のプロジェクトディレクトリの下に置かれ、そのプロジェクトにだけ効きます。

ここに向いているのは：

プロジェクト固有の背景
そのプロジェクトでしか成立しないルール
ディレクトリ構成の説明
重要文書の入口

たとえば、あるプロジェクトが財務を扱い、別のプロジェクトが人事を扱うなら、背景も制約も違うので、同じグローバル説明に混ぜるべきではありません。

どのレベルに置くかをどう判断するか

判断基準はシンプルです。

別のプロジェクトに移っても成立するなら user level に置く。

プロジェクトを変えた瞬間に成立しなくなるなら project level に置く。

最初の版をどう書き始めるか

よくある始め方は2つあります。

1. `/init` を使う

ターミナルで /init を実行して、Claude に現在のプロジェクトをスキャンさせ、基礎的な CLAUDE.md を自動生成してもらう方法です。

2. Claude に整理してもらう

他の人がどう CLAUDE.md を書いているかを Claude に調べてもらい、自分の状況に合わせて質問してもらった上で、最終的に自分向けの版に整理してもらうこともできます。

多くの場合、ゼロから自分で書くよりずっと楽です。

とても実用的な習慣

長く協業していると、「これは今後も必ず覚えておくべきだ」「これは二度と繰り返してほしくない」と思うことが出てきます。そういう内容は、そのまま CLAUDE.md に書き足していくと便利です。

ただし、その前に考えるべきことがあります。

それはグローバルルールか
それとも今のプロジェクト専用のルールか

何でも1つのファイルに詰め込まないことが大切です。

第2層：`Rules`

次が Rules です。

CLAUDE.md との最大の違いは、ファイル形式ではなくロードの仕方です。

CLAUDE.md は何をしていても常に読まれます。

一方、Rules の強みは 条件付きで読み込める ことです。

つまり、特定のパス、ファイル、ツール、場面でだけ、そのルールを読ませることができます。

なぜ条件付きロードが重要なのか

コンテキスト空間は常に限られています。

すべてのルールを無差別に毎回押し込むと、次の2つが起きます。

モデルの負担が増える
本当に重要なルールが埋もれる

必要なときに必要な情報だけ読ませる。これが条件付きロードの価値です。

`CLAUDE.md` から `Rules` に移すべきタイミング

典型的には2つあります。

1. `CLAUDE.md` が長くなりすぎたとき

CLAUDE.md が 200 行を超え始め、ルールが増えすぎて重要な内容が薄まってきたら、一部を切り出すタイミングです。

2. 特定のルールが特定のパスにしか関係しないとき

たとえば、あるルールが：

Python スクリプトにだけ有効
hooks ディレクトリにだけ有効
特定のサブプロジェクトにだけ有効

のように、適用対象が明確なら、それは Rules に移したほうが自然です。

`Rules` が最も向いている場面

典型的なのは「特定状況・特定パス・特定ファイル種別」です。

たとえば：

hook ファイルにだけ適用したい規約
特定種類のスクリプトだけで守らせたいコーディング規則
特定ディレクトリだけで有効な作業方針

そうした内容を CLAUDE.md に入れ続けるのは、あまり効率的ではありません。

第3層：`Memory`

3つ目の層が Memory です。

これも CLAUDE.md や Rules と同じくコンテキストに入りますが、本質的な違いがあります。

CLAUDE.md はあなたが意図的に定義するものです。

Memory は、協業の中で Claude が自分用に残すメモに近いものです。

`Memory` に入るもの

Claude が「これは覚えておく価値がある」「しばらく保持したほうがよい」と判断した内容は Memory に入ります。

たとえば：

あなたが修正したやり方
最近追加された好み
現在のプロジェクトの一時的な状態
今日終わらず、明日続きが必要なこと
最近誰と協業しているか
最近出てきた個人的な情報や文脈

つまり、Memory は長期制度というより、動的な知識に近いのです。

最初の2層との違い

簡単に分けるなら：

CLAUDE.md / Rules：長期的、制度的、明示的なルール
Memory：一時的、動的、作業の中で新しく得た理解

ここ数日しか有効でないことや、状態が継続的に変わることなら、長期ルールではなく Memory に向いています。

`Memory` は手動でも書ける

Memory は自動整理されることがありますが、こちらから明示的に指示して書かせることもできます。

たとえば：

明日やることを覚えておいて
誰の状況を追う必要があるか覚えておいて
今月のプロジェクトの重要な節目を覚えておいて

といった内容です。

また、/memory コマンドで現在の記憶を確認し、手動で編集・削除することもできます。

ただ、私自身はあまり頻繁に手で管理しません。Claude 側でも古くなった記憶を定期的に整理できるからです。

第4層：`Hooks`

最後であり、最も重要かつ上級なのが Hooks です。

ここまでの CLAUDE.md、Rules、Memory は、いずれも最終的には自然言語の指示です。

ルールを書けば、モデルはたいてい従います。ですが、それでも「解釈してから実行する」ものです。

自然言語にとどまる限り、いくつかの問題が残ります。

ときどき見落とす
ルールが増えると注意が分散する
状況によっては、そのルールを重要でないと自己判断する

これは書き方が悪いのではなく、自然言語ルールが 100% 強制にはなりにくいという性質によるものです。

`Hooks` の本質

Hooks は自然言語の説明ではありません。スクリプトです。

イベントで発火する、プログラムレベルの強制ロジックです。

あるイベントが起きれば、そのロジックは必ず実行されます。モデルの判断で飛ばされることはありません。

これが Hooks の最大の価値です。

「守るべき」から「必ず実行される」へ変えることです。

どんなときに `Hooks` に上げるべきか

もし、あるルールをすでに CLAUDE.md や Rules に書いてあるのに、Claude がときどき守り損ねる。そして、その見落としのコストが高い。そういう場合は Hooks に上げるべきです。

要するに：

低リスクならルール
高リスクなら Hooks

典型的な `Hooks` の場面

最も典型的なのは、絶対にミスしてほしくない操作です。たとえば：

メール送信前の確認
Slack、Outlook、Gmail 送信前の確認
危険なファイル削除の遮断
パスワードや API Key の外部送信のブロック

こうした内容が自然言語ルールだけだと、いつか忙しいタイミングでミスが起きる可能性があります。

でも Hooks にしておけば、イベント発生時に必ず止められます。

これは本当の意味でのプログラム的な安全柵です。

`Hooks` のよくあるトリガー地点

Hooks はさまざまな段階に設定できます。たとえば：

会話開始時にリマインドを入れる
ツール実行前に条件を確認する
ツール実行後に結果を検証する

専門用語を全部知っている必要はありません。

多くの場合、「こういう要件がある」「これを hook にすべきか」と明確に説明できれば、Claude が一緒に設計してくれます。

また、/hook コマンドで現在設定されている hooks を確認することもできます。

より実用的な導入順

この4層をつなげて運用するなら、私なら次の順番を勧めます。

ステップ1：まず `/init` で基本版 `CLAUDE.md` を作る

最初から完璧なルール文書を手書きしようとしないことです。

まずは Claude にプロジェクトを見てもらい、たたき台を作ってもらって、そこから育てていくのが自然です。

ステップ2：使いながら足していく

協業の中で、

今後も必ず覚えてほしい
このミスは二度と起こしてほしくない
この好みは毎回効いてほしい

というものが見つかったら、CLAUDE.md に追加していきます。

ステップ3：`CLAUDE.md` が長くなったら `Rules` に分ける

CLAUDE.md がどんどん長くなり、すべてのルールが安定して効かなくなってきたら分割します。

何がグローバルルールか
何が特定パス専用か

後者を Rules に移し、条件付きロードにします。

ステップ4：高リスクなものを `Hooks` に上げる

書いてあるのにまだ漏れる。そして漏れると危険。そういうものは自然言語のままにせず、Hooks に上げます。

つまり「リマインド」を「強制実行」に変えるわけです。

ステップ5：一時状態は `Memory` に任せる

期限があるもの、変化するもの、長期制度ではないものは、何でも CLAUDE.md に入れないことです。

たとえば：

現在のプロジェクト進捗
最近の協業相手
最近増えた好み
直近の計画や ToDo

こうしたものは Memory に持たせたほうが、コンテキストもすっきりし、モデルの挙動も安定しやすくなります。

4層それぞれに何を入れるか

手早く覚えるなら、次の整理で十分です。

CLAUDE.md：長期的な共通認識、グローバルな説明、プロジェクトの基礎背景
Rules：パスや場面ごとに読み込む専門ルール
Memory：動的な知識、一時状態、最近学んだこと
Hooks：高リスク操作をプログラム的に強制制御する層

まとめ

Claude Code を「コードを書けるチャット画面」として使う人は多いですが、深く使うほど、それは長期協業のための知的な作業台に近いと分かってきます。

重要なのは毎回の指示文だけではありません。安定していて、分かりやすく、積み重ねていける環境を与えられているかどうかです。

この4層、

CLAUDE.md
Rules
Memory
Hooks

をきちんと組めるようになると、あなたとモデルの協業品質はかなり大きく上がります。

毎回ゼロから「自分が誰で、どう働いて、何をしてはいけないか」を説明し直す必要がなくなり、それらが環境の一部として定着するからです。

それこそが、強いモデルを本当に成熟した道具として使うための重要な一歩です。

Claude Code のマルチエージェント協調: Subagents と Agent Teams はどう使い分けるか

Wed, 22 Apr 2026 21:35:52 +0800

Claude Code でマルチエージェント協調を考えるとき、最も混同しやすいのが Subagents と Agent Teams です。どちらも「複数の Agent を動かして一緒に作業する」ように見えますが、実際には想定している使い方が異なります。簡単に言えば、前者は独立したタスクを切り出して処理するのに向いており、後者は複数の Agent が同じテーマについて継続的に協力し、相互に検証しながら進めるのに向いています。

もし Skill を使ったことがあるなら、まずは次のように理解すると分かりやすいです。

Skill は手順やルールを定義する
Subagent や Agent teammate は実際の作業を行う

つまり重要なのは、どちらが「上位」かではなく、どの種類の協調課題を解きたいのかです。

Subagents: サイドタスクを切り出す

Subagents は、現在のセッションから一時的に送り出す分身に近い存在です。各分身は独自のコンテキストウィンドウを持ち、作業後は結果の要約だけを返します。そのため、メインの会話は大量の中間ログや出力で埋まりにくくなります。

この仕組みには、実務上かなり分かりやすい利点があります。

メインスレッドがきれいなままで、テストログや検索結果、長い出力で汚れにくい
相互依存のない調査や実行タスクを並列化できる
「結果だけ返してくれればよい」タイプの仕事に向いている

元記事では、Claude Code には次の 3 種類の組み込み Subagent があると説明されています。

Explore: 読み取り専用で、コードベースの高速検索に向く
Plan: 読み取り専用で、plan mode 中のバックグラウンド情報収集に向く
General-purpose: 読み書き可能で、探索と編集を組み合わせる仕事に向く

カスタム Subagent

組み込みのものだけでは足りない場合は、自分で Subagent を定義できます。やり方はシンプルで、Markdown ファイルを用意するだけです。

.claude/agents/: 現在のプロジェクトでのみ有効
~/.claude/agents/: すべてのプロジェクトで有効

ファイル形式は次のようになります。

---
name: code-reviewer
description: Expert code review specialist. Proactively reviews code for quality, security, and maintainability. Use immediately after writing or modifying code.
tools: Read, Grep, Glob, Bash
model: inherit
---
You are a senior code reviewer ensuring high standards of code quality and security.

When invoked:

1. Run git diff to see recent changes
2. Focus on modified files
3. Begin review immediately

Review checklist:

- Code is clear and readable
- Functions and variables are well-named
- No duplicated code
- Proper error handling
- No exposed secrets or API keys
- Input validation implemented
- Good test coverage
- Performance considerations addressed
Provide feedback organized by priority:

- Critical issues (must fix)
- Warnings (should fix)
- Suggestions (consider improving)

Include specific examples of how to fix issues.

ここで特に重要なのは description です。Claude はこの説明を見て、いつこの Subagent を呼ぶべきか判断します。説明が正確であるほど、呼び出しの精度も上がりやすくなります。

ほかにも知っておくと便利な設定項目があります。

tools: 使用できるツールを制限する
model: sonnet、opus、haiku、inherit から選ぶ
permissionMode: 編集権限や権限プロンプトの挙動を制御する
memory: Subagent に対話をまたぐ記憶ディレクトリを与える

一時的にだけ使いたい場合は、CLI 経由で定義することもできます。

claude --agents '{
  "code-reviewer": {
    "description": "Expert code reviewer. Use proactively after code changes.",
    "prompt": "You are a senior code reviewer. Focus on code quality, security, and best practices.",
    "tools": ["Read", "Grep", "Glob", "Bash"],
    "model": "sonnet"
  }
}'

Subagents が向いている場面

Subagents が特に向いているのは、たとえば次のような仕事です。

テストを実行し、数千行のログではなく失敗要約だけをメイン会話に返す
相互依存しない複数モジュールの調査を並列に進める
「問題を見つける」と「修正する」を単純なパイプラインに分ける

たとえば次のような指示です。

`1`	`Research the authentication, database, and API modules in parallel using separate subagents`

`1`	`Use the code-reviewer subagent to find performance issues, then use the optimizer subagent to fix them`

一方で、タスクが何度も往復しながら調整を要する場合、複数段階で大量の文脈を共有する場合、あるいは変更が一つ二つのファイルに集中している場合は、Subagent を立てるよりメイン会話で直接処理したほうが楽なことが多いです。

Agent Teams: 複数の独立セッションで協調する

Agent Teams は別のレイヤーの機能です。1 つのセッション内で分身を出すのではなく、完全に独立した複数の Claude Code インスタンスを起動し、共有タスクリストを中心に協調させます。しかも、メンバー同士が直接メッセージを送り合うこともできます。

そのため、単なるサイドタスク処理というより、本当に小さなチームを作る感覚に近いです。

元記事では、これはまだ実験機能であり、先に有効化が必要だと説明されています。

{
    "env": {
        "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
    }
}

これを settings.json に追加すると、Claude に対して目的に応じた team を組ませることができます。たとえば次のような形です。

1
2
3

I'm designing a CLI tool that helps developers track TODO comments across
their codebase. Create an agent team to explore this from different angles: one
teammate on UX, one on technical architecture, one playing devil's advocate.

Agent Teams の構成

Agent Team は主に次の 3 つで構成されます。

Team lead: あなたが使っているメインセッション。編成、割り振り、要約を担当する
Teammates: 複数の独立した Claude Code インスタンス
Task list と Mailbox: 共有タスクリストとメッセージ経路

Subagents との最大の違いは、teammates 同士が直接やり取りできることです。毎回 lead を経由する必要はありません。タスク状態は通常 pending、in progress、completed の間を移り、1 つ終えた teammate は次のタスクを引き取ることもできます。

Agent Teams が向いている場面

複数視点からの検討、結論への異議申し立て、仮説同士の競合、あるいはモジュール単位の並列開発が必要なときは、Agent Teams のほうが適しています。

記事では次のような典型例が挙げられています。

同じ PR を複数 reviewer が並列でレビューし、それぞれ異なる観点を見る
同じ bug に対して複数の Agent が異なる仮説を立て、互いに反証する
フロントエンド、バックエンド、テストが別々の領域を並列で進める

たとえば並列コードレビューでは、次のように指示できます。

Create an agent team to review PR #142. Spawn three reviewers:
- One focused on security implications
- One checking performance impact
- One validating test coverage
Have them each review and report findings.

また、討論型のデバッグでは次のような使い方ができます。

Users report the app exits after one message instead of staying connected.
Spawn 5 agent teammates to investigate different hypotheses. Have them talk to
each other to try to disprove each other's theories, like a scientific
debate. Update the findings doc with whatever consensus emerges.

この種の仕事に共通しているのは、単に 1 つの答えが欲しいのではなく、複数の Agent が判断を持ち寄り、前提を揺さぶり合いながら、より確かな結論に収束していくことです。

どう使い分けるか

手早く判断したいなら、次のように覚えると分かりやすいです。

結果だけ持ち帰ればよいなら Subagents
議論や相互検証が必要なら Agent Teams

もう少し整理すると、主な違いは次の通りです。

通信方法: Subagents は主にメイン会話へ結果を返すが、Agent Teams はメンバー同士で直接やり取りできる
調整方法: Subagents はメイン会話側のオーケストレーションに依存しやすいが、Agent Teams は共有タスクリストをもとに各メンバーが自律的に動ける
Token コスト: Subagents のほうが軽く、Agent Teams は各 teammate が独立インスタンスのため高くなりやすい
向いている仕事: Subagents は独立性が高く結果志向の仕事向き、Agent Teams は議論や相互検証が重要な仕事向き

実運用で気をつけたいこと

Agent Teams は強力ですが、だからといってすべてのタスクで team を組むべきというわけではありません。記事では特に次のような現実的な注意点が挙げられています。

token 消費が明らかに大きい
複数 teammate が同じファイルを同時に編集すると、上書き競合が起きやすい
teammate が多すぎると調整コストが増え、成果が伸びるとは限らない

そのため、比較的安全な進め方としては次のようになります。

まずは 3〜5 人程度の teammate から始める
モジュールやファイル単位で仕事を分け、編集衝突を避ける
lead が早まって teammate の仕事に手を出し始めたら、先に待つよう明示する

また、現時点の実験版には次のような制約もあります。

/resume と /rewind で in-process teammates を復元できない
タスク状態が遅れて反映され、手動での更新が必要になることがある
1 人の lead が同時に扱える team は 1 つだけ
teammate がさらに子 team を作ることはできない

まとめ

この 2 つの機能は、互いの代替ではありません。解いている協調課題そのものが違います。

目的が「サイドタスクを並列化し、メインの文脈をきれいに保つこと」なら、まずは Subagents を使うのが自然です。目的が「複数の Agent に小さなチームのように協力させ、議論し、相互検証させること」なら、Agent Teams が向いています。

実際のタスクで一度試してみると、違いはかなり早く体感できます。片方は文脈の分離と結果回収に強く、もう片方は多視点での協調と継続的なやり取りに強い、という違いです。

nuwa-skill: 「ある人を蒸留する」を発想から実行可能なワークフローへ

Wed, 22 Apr 2026 16:20:00 +0800

[alchaincyf/nuwa-skill](https://github.com/alchaincyf/nuwa-skill) を見ると、まず「AI に有名人の口調で答えさせるものだろう」と思うかもしれません。ですが本当に面白いのは、どれだけ似ているかではありません。このプロジェクトは「ある人がどう考えるかを蒸留する」ことを、繰り返し実行できるワークフローにしようとしている点にあります。

それが成立すれば、価値は単なる面白いキャラクター prompt をいくつか作ることにとどまりません。ある人の判断フレーム、注目点、よく使うヒューリスティック、表現の癖を、何度も呼び出せる skill として定着させられるからです。欲しいのは「その人が言いそうな一文」ではなく、「その人ならこの問題をどう見て、何を優先し、何を疑うか」に近い作業インターフェースです。

これは「模倣」ではなく「モデリング」を解く

いわゆる人物 prompt の多くは、本質的にはスタイルの上貼りです。

よくある指示は次のようなものです。

ある人物の口調で話す
その人の決まり文句を多く使う
公開発言の言い回しをできるだけ真似する

こうしたやり方はデモでは目を引きますが、実務に入ると崩れやすいです。理由は単純で、口調は表層であり、判断構造こそが核だからです。人物に識別性があるのは、好んで使う単語があるからではなく、問題に向き合うときに一定の切り込み方をするからです。

nuwa-skill の方向性は、そうした「安定した方法」を抽出することに近いです。言い換えれば、関心があるのは「どうすればその人っぽく話せるか」ではなく、「どうすればその人っぽく考えられるか」です。

より完全なワークフロー

リポジトリの説明を見ると、nuwa-skill が目指しているのはエンドツーエンドの流れです。人名を入力すると、自動で調査、抽出、検証を行い、その結果を Claude Code で呼び出せる skill としてまとめる、という形です。

この考え方にはいくつか重要な変化があります。

第一に、蒸留対象は自分のチームの同僚でなくてもよいという前提です。この種の発想に初めて触れると、「優秀な同僚のやり方を残す」ことをまず思い浮かべる人が多いでしょう。それにも価値はありますが、学習サンプルが限られ、内部の経験に偏りやすいという境界もあります。nuwa-skill は対象をもっと広げ、起業家、投資家、科学者、プロダクトマネージャー、書き手のような人たちまで含めています。

第二に、強調されているのは手作業で prompt を組み立てることではなく、「自動で完了する」ことです。この手の能力を実用化するうえで本当に大事なのは、華やかな prompt 文ではなく、資料収集、観点の整理、パターン抽出、結果の検証を安定して回せるかどうかです。どこか一工程でも全面的に手作業へ依存すると、再利用コストは急激に上がります。

第三に、出力を一度きりの会話ではなく skill にしようとしていることです。前者なら繰り返し呼び出し、組み合わせ、改善できます。後者はその場の文脈でしか効かず、数ターンで崩れがちです。

なぜこの方向に注目する価値があるのか

AI を質問応答マシンとして見るなら、自然な使い方は「答えをください」です。ですが AI を作業台として見るなら、問いは「この問題を見る方法をください」に変わります。

nuwa-skill の価値は後者に寄っています。

たとえばプロダクトの意思決定に向き合うとき、欲しいのは一つの正解ではなく、鋭く異なる複数の分析フレームかもしれません。

長期的な複利から見る人
リソース制約から見る人
ユーザー体験の一貫性から見る人
市場参入のタイミングから見る人

こうしたフレームを安定してパッケージ化できれば、AI の役割は「文章を一段落書くもの」から「視点を素早く切り替えるもの」へ変わります。これは名言の模倣よりずっと実用的です。なぜなら、意思決定の質に直接効くからです。

最も魅力的な点: 暗黙知を呼び出せる資産に変えること

価値の高い能力ほど、そもそも SOP に書きにくいものです。

ある人の判断がなぜ他の人よりも的確なのかは、多くの場合、明示的なルールをたくさん知っているからではありません。長い実践の中で、暗黙のフィルタリング機構を作ってきたからです。

どのシグナルを優先して見るか
どのノイズをすぐ切り捨てるか
どの問いを分解して考えるか
どの問いを反転させてみるか
どの結論はさらに証拠を待つべきか

こうした能力は、本人でも常に明快に言語化できるとは限らないため、普段は残しにくいです。だからこそ、構造化して抽出できるなら価値が高い。nuwa-skill が惹きつけるのはこの点です。表層的な知識移送ではなく、認知習慣の再構成を扱おうとしているのです。

どんな場面に向いているか

この種の skill は、特に次のような場面で有効だと思います。

1. 意思決定前の多視点レビュー

すでに案はあるものの、自分が慣れた道筋でしか考えていない気がするとき、異なる「人物視点」に切り替えて同じ問題を見直す方が、元の文章をそのまま膨らませるより価値があります。

2. 特定タイプの達人の判断フレームを学ぶ

達人から学ぶとき、多くの人は名言を集め、インタビューを見て、要約を写します。しかし最後に残るのは、たいてい数個の印象的な言葉だけです。思考パターンを skill 化できれば、学び方は「実際の問いを持ち込んで何度も呼び出す」ものに近づき、「静的な抜き書きを大量に作る」ことから離れます。

3. チームで分析スタイルを共有する

チームに本当に不足しがちなのは、文書そのものではなく、「私たちは問題にぶつかったとき普段どう考えるか」という共有です。この流れが成熟すれば、組織内の強い実務家の方法論を残す用途にも逆向きで使えるでしょう。ただ、このプロジェクトがそれだけに能力を閉じ込めるつもりではないことは明らかです。

この種のプロジェクトで本当に難しいこと

もちろん、方向性が魅力的だからといって、難題が解けたわけではありません。

本当の難しさは skill をインストールすることではなく、むしろ次の点にあります。

情報源が十分に信頼できるか
抽出されたパターンが安定しているか、単なる断片的な語料の錯覚ではないか
モデルが人物のフレームを使って分析しているのか、それとも一般的な印象をなぞっているだけなのか
複数の人物の境界がモデル内部で曖昧にならないか

つまり本当に重要なのは、「もっともらしい文章を出せるか」ではなく、「この skill が生む認知フレームが多様なタスクに耐えて再利用できるか」です。今後、検証工程がさらに深まれば、この種のプロジェクトの信頼性は大きく上がるはずです。

なぜこれは「prompt テンプレート集」より一歩先なのか

これまで多くのプロジェクトは、この能力をテンプレート集として扱ってきました。人物ごとに一つ prompt を用意し、ユーザーがコピーして使う形です。しかしテンプレート集は本質的に静的資産であり、更新は遅く、検証は弱く、完全な制作フローにもなりにくいです。

nuwa-skill が一歩進んでいるのは、「人物蒸留」をテンプレートの問題からワークフローの問題へ進めている点です。

重心が「prompt を一つ書く」ことから、「人物 skill をどう体系的に生成し、検証し、改善するか」へ移ると、この営みはひらめきよりも工学に近くなります。長く使いたい人にとって重要なのは、明らかにこちらです。

結び

nuwa-skill が面白いのは、AI を有名人のものまねショーにしたからではありません。「ある人の考え方をどう学ぶか」を、実行可能で、再利用できて、反復改善できる方向へ一歩進めたからです。

多くの人物 prompt が解いているのが「誰かのように話す」ことだとすれば、このプロジェクトが解こうとしているのは「誰かのように問題を見る」ことです。前者はデモ向きで、後者こそ生産性ツールに近いと言えます。

参考リンク

GitHub リポジトリ: https://github.com/alchaincyf/nuwa-skill
プロジェクト説明: https://github.com/alchaincyf/nuwa-skill/blob/main/README.md
Skill 定義: https://github.com/alchaincyf/nuwa-skill/blob/main/SKILL.md

Karpathy の 65 行の CLAUDE.md：AI コーディングで三つの典型的なミスを減らす

Sun, 19 Apr 2026 18:27:23 +0800

最近、AI コーディングに関する GitHub プロジェクトが注目を集めている。中心にあるのは複雑なコードではなく、およそ 65 行の CLAUDE.md ファイルだ。このプロジェクトが多くの star を集めた理由は、技術実装の複雑さではない。AI にコードを書かせるとき、多くの人が繰り返し遭遇する問題をうまく捉えているからだ。

背景には、Andrej Karpathy による AI コーディングへの観察がある。Karpathy は AI 分野で大きな影響力を持つ教育者でありエンジニアだ。スタンフォード大学の博士で、OpenAI の初期にも関わり、Tesla では Autopilot の視覚システムを担当した。その後も大規模モデル、教育、AI ツールについて発信を続けているため、彼がプログラミング手法の変化について語ると、多くの開発者が注目する。

彼は、Claude Code を数週間使ったあと、自分のプログラミングスタイルが大きく変わったと述べている。以前はおよそ 80% を手書きし、20% を AI に補助させていた。今は 80% を AI に書かせ、自分は 20% を修正する感覚に近いという。自然言語で LLM に何を書くべきか伝えるので、「英語でプログラミングしている」ようなものだと表現している。

一方で、彼は AI コーディングにありがちな問題も指摘している。

01 誤った仮定

一つ目の問題は、モデルがユーザーの代わりに勝手な仮定を置き、その仮定に沿って書き進めてしまうことだ。モデルは必ずしも自分の混乱を管理しないし、要件が曖昧なときに立ち止まって質問するとも限らない。

たとえばユーザーが「ユーザーのエクスポート機能を追加して」とだけ言った場合、モデルは全ユーザーを出力する、JSON 形式にする、ローカルファイルに書き出す、権限や項目は確認不要だ、と勝手に決めるかもしれない。コードが完成してから、ユーザーはモデルの理解が実際のシナリオとずれていたことに気づく。

よりよい進め方は、不確かな点を先に列挙することだ。全ユーザーを出力するのか、フィルタ後の結果なのか。ブラウザでダウンロードするのか、バックグラウンドジョブなのか。必要な項目は何か。データ量はどれくらいか。権限制御はあるのか。こうした点を確認しないまま速く書いても、ずれが大きくなるだけだ。

02 過度な複雑化

二つ目の問題は、モデルが簡単な問題を複雑にしがちなことだ。一つの関数で済む問題に対して、抽象クラス、ストラテジーパターン、ファクトリーパターン、設定レイヤー、将来使うかもしれない拡張ポイントを山ほど追加することがある。

こうしたコードは一見エンジニアリングされているように見えるが、実際には保守コストを増やす。AI は大量の構造を素早く生成するのが得意だが、その構造が本当に必要かを常に判断できるわけではない。その結果、100 行で済むタスクが 1,000 行に膨らむ。

判断基準はシンプルだ。経験あるエンジニアがその変更を見て、過剰設計だと感じるかどうか。答えが yes なら、余分な層を削り、今の問題を解くために必要な最小限のコードに戻すべきだ。

03 付随的な被害

三つ目の問題は、モデルが十分に理解していないコードを変更したり削除したりすることだ。小さな bug を直している途中で、ついでにコメントを変えたり、フォーマットを整えたり、未使用に見える import を消したり、現在のタスクと無関係なロジックにまで手を入れることがある。

こうした「ついでの改善」は危険だ。変更範囲を広げ、レビューを難しくするからだ。ユーザーは空の email でバリデータが落ちる問題だけを直したいのに、モデルが email 検証を強化し、ユーザー名検証を追加し、ドキュメント文字列まで書き換えると、どの行が挙動を変えたのか分かりにくくなる。

より安全な原則は、必要なコードだけを変更し、自分の変更によって生まれた問題だけを片付けることだ。もともと存在していた dead code、フォーマットの問題、歴史的な負債は、明示的に依頼されていない限り触らない。必要なら一言指摘するだけでよい。

04 不満を CLAUDE.md に変える

Karpathy の見解が広く共有されたあと、開発者の Forrest Cheung は賢いことをした。これらの不満を、実行可能な行動指針として整理し、CLAUDE.md ファイルに書き込んだのだ。

このプロジェクトには複雑なコードはない。重要なのは、AI コーディングで問題が起きやすい部分を、明確な作業ルールに変えたことだ。大きく四つの原則にまとめられる。

一つ目は、書く前に考えること。黙って仮定しない。混乱を隠さない。要件に複数の解釈があるなら列挙する。より簡単な案があるなら伝える。確認が必要なら質問し、反論すべきときは反論する。

二つ目は、シンプルさを優先すること。求められていない機能を追加しない。一度しか使わないコードを抽象化しない。余計な設定を増やさない。ほぼ起きないケースのために大量の防御コードを書かない。50 行で済むなら 200 行にしない。

三つ目は、正確に変更すること。すべての変更行は、ユーザーの依頼に直接結びついているべきだ。近くのコードをついでに改善しない。壊れていないものをリファクタリングしない。できるだけ既存プロジェクトのスタイルに合わせる。

四つ目は、目標駆動で進めること。モデルに曖昧な指示だけを渡すのではなく、検証可能な成功基準を与える。たとえば「bug を直す」は「bug を再現するテストを書き、それを通す」にできる。「バリデーションを追加する」は「不正入力のテストを書き、それを通す」にできる。成功基準が明確なほど、モデルは完了に向けて自分でループしやすくなる。

05 なぜ広まったのか

このプロジェクトが広まったのは、内容が難解だからではない。実際の開発に近いからだ。

AI にコードを書かせたことがある人の多くは、似た場面を経験している。モデルが自信満々に要件を誤解する。コードがどんどん複雑になる。触るべきでない場所を変更する。CLAUDE.md の価値は、こうした経験をプロジェクトに置ける協作ルールに変えたことにある。

導入の敷居も低い。複雑な連携は不要で、一つのファイルから始められる。Karpathy 本人の影響力に加え、プロジェクト内に実践的な比較例があるため、Claude Code ユーザーや AI コーディングコミュニティの間で自然に広まった。

さらに重要なのは、この種のルールが Claude Code だけに限られないことだ。どの AI コーディングツールを使っても、本質的な問題は似ている。モデルは、いつ質問すべきか、いつ単純化すべきか、いつ手を止めるべきか、どうやってタスク完了を判断するかを知る必要がある。

06 普通の開発者への示唆

普通の開発者にとっての示唆はシンプルだ。AI コーディングは、一文の要件をモデルに投げて奇跡を待つものではない。本当に有効なのは、モデルに境界を与えることだ。

要件が不明確なときは、まず仮定を表に出させる。実装が複雑になり始めたら、最小の実用解に戻らせる。コードを変更するときは、タスクの目的だけに集中させる。完了時には、テスト、コマンド、明確なチェックポイントで結果を検証する。

AI がコードを書く能力はすでに高い。それでも、よい協作上の制約は必要だ。短い CLAUDE.md がこれほど注目されたことは、開発者が求めているのはより賢いモデルだけではなく、より信頼できる作業方法でもあることを示している。

簡単にまとめると：

書く前に考え、誤った仮定を減らす。
シンプルさを優先し、過度な設計を避ける。
正確に変更し、変更範囲を制御する。
検証可能な成功基準で、目標に向かって進める。

この四つは複雑ではないが、実用的だ。AI コーディングが本当に効率を上げる前提は、モデルにより多く書かせることではない。より正確に、より少なく、より制御された形で書かせることだ。

Claude Codeの使用枠を節約する：モデル選択、コンテキスト、キャッシュ、/compact

Sun, 19 Apr 2026 15:29:06 +0800

最近、Claude Code や Claude Max を使っていて同じ問題に当たる人が増えています。Pro、Max 5x、Max 20x を契約しているのに、少し使っただけで使用量の警告が出る、あるいは次のリセットを待つ必要がある、というものです。特に大きなプロジェクトで Claude Code に大量のファイルを読ませたり、複雑な bug を修正させたり、長いタスクを走らせたりすると、この感覚はかなり強くなります。

先に結論を書くと、使用枠は「時間」で線形に減るわけではありません。モデル、コンテキスト長、添付ファイル、コードベースの大きさ、会話履歴、ツール呼び出し、現在の容量によって変わります。同じ5時間ウィンドウでも、長く使える人もいれば、十数分で上限に近づく人もいます。多くの場合、アカウントがおかしいのではなく、1回ごとのリクエストが重すぎます。

この記事では、使用枠を節約するための実用的な習慣を整理します。

01 まず Claude の使用ウィンドウを理解する

Claude Pro と Max には使用制限があります。Claude Code の使用量は、Claude のWeb、デスクトップ、モバイルアプリと同じサブスクリプション枠を共有します。公式ヘルプでは、送信できるメッセージ数はメッセージの長さ、添付ファイルの大きさ、現在の会話の長さ、使うモデルや機能に左右されると説明されています。Claude Code ではさらに、プロジェクトの複雑さ、コードベースの大きさ、自動承認設定なども影響します。

大まかにはこう考えるとよいです。

Pro：軽い利用と小さなプロジェクト向け。
Max 5x：より頻繁な利用と大きめのコードベース向け。
Max 20x：重めの日常利用や高頻度の共同作業向け。
使用ウィンドウは5時間セッション単位でリセットされる。
長いメッセージ、長い会話、大きなファイル、複雑なタスクは使用量を早く消費する。
Opus のような強いモデルは Sonnet より早く制限に近づきやすい。

そのため、「20分しか使っていない」という説明だけでは状況は分かりません。重要なのは、その20分で Claude がどれだけのコンテキストを読んだか、どのモデルを使ったか、大きなファイルを何度も処理したか、同じ長い会話にタスクを追加し続けたかです。

02 まずやること：最も高いモデルをデフォルトにしない

Claude 系列は、おおよそ次のように使い分けられます。

Opus：最も強力。複雑な推論、設計判断、難しい bug に向く。
Sonnet：能力とコストのバランスがよく、日常的なコーディング作業に向く。
Haiku：軽量。簡単な分類、要約、形式変換などに向く。

日常的なスクリプト作成、小さな bug 修正、ドキュメント整理、コード説明なら、多くの場合 Sonnet で十分です。Opus は次のような場面に残しておくほうがよいです。

複雑なアーキテクチャ設計。
複数ファイルにまたがる深いリファクタリング。
再現しにくい bug。
長い推論が必要なトラブルシュート。
通常モデルが明らかに詰まったタスク。

Claude Code では /model でモデルを切り替えられますし、/config でデフォルトも設定できます。安定した使い方は、普段は Sonnet、重要な局面だけ Opus に切り替えることです。最初から最後まで Opus で押し切る必要はありません。

03 次にやること：コンテキストを制御し、古いタスクを引きずらない

コンテキストが長くなるほど、Claude が毎回処理する内容が増え、使用量も増えます。Claude Code の公式ドキュメントでも、コンテキストを能動的に管理することが推奨されています。

無関係なタスクに切り替えるときは /clear で履歴を消す。
現在のタスクが一段落したが重要な文脈は残したいときは /compact で圧縮する。
何がコンテキストを使っているか知りたいときは /context を使う。
状態を常に見たい場合は status line を設定する。

使いやすいリズムは次の通りです。

小さな段階が終わった：/compact
大きなタスクが終わった：/clear
無関係な作業に切り替える：/clear
コンテキスト使用量が高くなってきた：早めに /compact

/compact は前の会話を要約し、重要なタスク状態、結論、ファイルパス、TODO を残しつつ、後続リクエストに持ち込む履歴を減らします。後ろに重点を書いてもよいです。

`1`	`/compact 変更済みファイル、テスト結果、残りTODO、重要な設計判断を残す`

自動圧縮を待つ必要はありません。公式ドキュメントでは、Claude Code はコンテキストが上限に近づくと自動圧縮すると説明されていますが、段階の区切りで手動圧縮するほうが制御しやすいです。

04 三つ目：長い会話と大きなファイルは毎回のリクエストを重くする

「もう一言聞いただけだから安いはず」と思いがちです。しかし長い会話では、その一言の背後に大量の履歴、ファイル要約、ツール定義、システムルールが付いてくることがあります。

特にコンテキストを増やしやすいものは次の通りです。

ずっと消していない長い会話。
Claude に大きなファイル全体を読ませること。
長いログ、ビルド出力、テスト出力を貼ること。
スクリーンショットや画像を一度に大量に入れること。
リポジトリ全体を何度もスキャンさせること。
長すぎる CLAUDE.md。
多すぎる MCP server。

節約するなら、ログは重要なエラーだけ、テスト出力は失敗部分だけにします。大きなファイルは、まず rg、head、tail、シンボル検索で位置を絞り、必要な部分だけ読ませます。コマンドラインで絞れる内容を、丸ごとコンテキストに入れないほうがよいです。

05 四つ目：キャッシュを理解する。ただし過信しない

Anthropic の Prompt Caching は、繰り返される prompt の前方部分をキャッシュします。デフォルトのキャッシュ寿命は5分で、1時間キャッシュもサポートされています。キャッシュがヒットすると、繰り返し使う大きなコンテキストを毎回完全に再処理せずに済むため、コスト削減や使用枠の効率改善につながります。

ただしキャッシュには制限があります。

テキストや画像を含め、内容が完全一致する必要がある。
デフォルトのキャッシュは短命。
モデル、ツール、システムプロンプト、コンテキスト構造を変えるとヒット率が下がることがある。
出力 token はキャッシュで消えるわけではなく、回答生成分は必要。
Claude Code が具体的にどうキャッシュを使うかは製品実装の詳細なので、永続的な「無料メモリ」と考えないほうがよい。

実際の利用で大事なのは、キャッシュの細部を研究することではなく、セッションを安定させることです。

同じ段階ではモデルを頻繁に切り替えない。
作業中に大量のルールを何度も書き換えない。
同じタスクの途中で新しい画像を次々追加しない。
長いタスクを長時間放置したあと、いきなり大きなリクエストを投げない。
段階が終わったら /compact する。

こうすると、繰り返しのコンテキストを再利用しやすくなり、後続リクエストも軽くなります。

06 ピーク時間について：避けられるなら避ける。ただし固定公式にしない

ネット上では、特定の時間帯は使用枠が厳しいという話をよく見かけます。公式ヘルプの表現はもっと慎重で、送信可能数は Claude の現在の容量、会話の長さ、添付ファイル、モデル、機能に影響されるとされています。つまり、ピーク時の容量は体験に影響する可能性がありますが、特定地域の特定時間を永続的な固定ルールとして扱うべきではありません。

実用的には次のように考えます。

大きなリファクタリングや重い分析は、自分のネットワークとサービスが安定している時間に行う。
すぐ離席する直前に超長タスクを始めない。
長時間離れる予定があるなら、先に /compact または /clear する。
小さな修正なら、長いコンテキストのまま Opus で強引に走らせない。

固定の「何時から何時は使わない」というルールを覚えるより、このほうが安定します。

07 CLAUDE.md、rules、MCP、skills を軽くする

Claude Code はセッション内でプロジェクトルール、ツール情報、一部の環境コンテキストを読み込みます。公式ドキュメントでも、汎用ルールと専用ルールを分け、毎回大量の無関係な内容を読み込まないようにすることが推奨されています。

おすすめの分け方は次の通りです。

CLAUDE.md：全体に常に適用される最小限のルールだけ。
rules：特定パスや特定ファイルタイプに必要なルール。
skills：投稿、デプロイ、画像生成、コードコミットなどの特定ワークフロー。
MCP：現在のタスクで本当に使う server だけ有効にする。

CLAUDE.md が何百行、何千行もあると、毎回その分を持ち込みます。たまにしか使わない手順は skill に移し、必要なときだけ呼び出すほうが軽くなります。

MCP も同じです。ツールが多いほど効率が上がるとは限りません。Claude Code のドキュメントでは、/mcp で不要な server を確認して無効化し、/context で何がコンテキストを使っているか確認できると説明されています。

08 実用コマンド一覧

日常的によく使うのは次のコマンドです。

/model

モデルを切り替える。通常は Sonnet、複雑な推論では Opus。

/clear

現在のコンテキストをクリアする。無関係なタスクに切り替えるときに使う。

`1`	`/compact`

会話履歴を圧縮する。段階が終わったが同じタスクを続けるときに使う。

`1`	`/context`

コンテキスト使用量を確認し、何が場所を取っているか調べる。

/status

現在のサブスクリプションや使用量関連の状態を見る。公式ヘルプでも残り割り当ての確認に推奨されています。

/mcp

MCP server を確認、管理し、現在使わないツールを無効化する。

API 課金で使っている場合は /cost も参考になります。ただし Pro/Max サブスクリプションでは、公式ドキュメントが /cost のドル見積もりは請求の基準ではないと説明しています。サブスクリプション利用者は /stats や /status の利用情報を見るほうが適しています。

09 使用枠を節約する作業フロー

使いやすい流れは次のようになります。

新しいタスクの前に /clear する。
デフォルトは Sonnet にする。
Claude にはまずプロジェクト構造と重要ファイルだけを読ませ、リポジトリ全体を一気に読ませない。
小さな段階が終わるたびに /compact する。
難しい詰まりどころだけ Opus に切り替える。
ログ、エラー、テスト出力は絞ってから渡す。
タスク完了後は /clear し、古いコンテキストを引きずって新しい作業を始めない。
定期的に CLAUDE.md、MCP、skills を見直し、常駐コンテキストを小さくする。

この流れの核心は、Claude に毎回「今本当に必要なもの」だけを見せることです。

10 まとめ

Claude Code の使用枠がすぐ尽きる原因は、たいてい1つではありません。高コストなモデル、消していない長い会話、多すぎるファイルやログ、重い MCP とルール、キャッシュ命中率の低下、ピーク時の容量変動が重なって起こります。

節約の要点はシンプルです。

日常作業は Sonnet を優先する。
Opus は本当に複雑な問題に残す。
段階が終わったら /compact。
タスクを切り替えるときは /clear。
/context でコンテキスト肥大化の原因を探す。
CLAUDE.md、rules、MCP、skills を軽くする。
リポジトリ全体、ログ全体、大量の画像をそのまま入れない。

同じ Pro や Max でも、どれだけ作業できるかはコンテキスト管理に大きく左右されます。コンテキストを小さくし、タスクの境界をはっきりさせると、Claude Code はかなり安定して使いやすくなります。

参考リンク

Claude Help Center：Using Claude Code with your Pro or Max plan：https://support.claude.com/en/articles/11145838-using-claude-code-with-your-pro-or-max-plan
Claude Help Center：About Claude’s Max Plan Usage：https://support.anthropic.com/en/articles/11014257-about-claude-s-max-plan-usage/
Claude Code Docs：Manage costs effectively：https://code.claude.com/docs/en/costs
Anthropic Docs：Prompt caching：https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching