AIコーディング on KnightLiブログ

GitHub AIオープンソースプロジェクト分類：Coding AgentからRAGナレッジベースまで

Thu, 21 May 2026 08:53:13 +0800

このページでは、GitHub上のAIプロジェクトを用途別に整理します。AIコーディングとCoding Agent、Agentスキルとワークフロー、RAGとナレッジベース、マルチモーダル制作、ローカルモデルと推論、垂直アプリケーションと自動化、AIアプリ開発基盤などの方向を扱います。新しいプロジェクトが増えた場合も、同じ構造で追加できます。

カテゴリ概要

カテゴリ	プロジェクト数	まず見るべき人
AIコーディングとCoding Agent	19	Claude Code、Codex、Cursor、ターミナルAgent、リポジトリ自動化をよく使う人
Agentスキルとワークフロー	7	AIコーディング、研究、制作フローを標準化したい人
RAG、ナレッジベース、メモリ	7	文書検索、ナレッジベース、長期メモリ、Webクロール、構造化抽出が必要な人
垂直アプリケーションと自動化	7	金融、取引、Xianyu監視、デスクトップ操作、ブラウザ自動化などを見たい人
マルチモーダルとコンテンツ制作	5	画像、動画、文字起こし、プロンプト集、コンテンツ配信を扱う人
AIアプリ開発基盤	3	AIアプリ、ブラウザ自動化、Prompt/MCPツールチェーンを構築する開発者
ローカルモデルと推論	1	ローカルDeepSeek、推論エンジン、ハードウェア適配に関心がある人

この分布から、現在のAIオープンソースプロジェクトではAIコーディングツールが最も多く、その次にAgentワークフロー、RAGナレッジベース、具体的な応用シナリオが続くことがわかります。純粋なモデル推論プロジェクトは少なめです。ローカルデプロイの多くは、単一のGitHubプロジェクトではなく、モデル、GPU、デプロイ方案を中心に整理されるためです。

AIコーディングとCoding Agent

このカテゴリは、コード理解、コード修正、エンジニアリングフロー、ターミナルAgentに焦点を当てます。最も大きいグループで、19 件のプロジェクトがあります。

プロジェクト	記事	GitHub	主な用途	向いている人
Ralph	Ralph：Claude CodeとAmpを自律開発ループにする	snarktank/ralph	PRD、計画、実行、レビューの流れでClaude Code / Ampを進める	Agentコーディングの流れを整えたい人
Claude-Mem	Claude-Mem：Claude Codeにセッション横断の長期メモリを追加する	thedotmack/claude-mem	Claude Codeにセッション横断メモリを追加	Claude Codeを頻繁に使う開発者
Claude Code Hooks Mastery	Claude Code Hooks Mastery：13個のHooksライフサイクル入門	disler/claude-code-hooks-mastery	Claude Code Hooksのライフサイクルと自動化制御を学ぶ	Claude Codeをカスタマイズしたい人
Compound Engineering Plugin	Compound Engineering Plugin：AIコーディングを計画、実行、レビューの循環にする	EveryInc/compound-engineering-plugin	AIコーディングを計画、実行、レビューに分ける	工学的なAIコーディングを重視する人
free-claude-code	free-claude-code：Claude CodeをOpenRouter、DeepSeek、ローカルモデルにつなぐ	Alishahryar1/free-claude-code	proxy経由でClaude Codeを複数モデルバックエンドに接続	Claude Codeのコストを下げたい人
Hermes Agent	Hermes Agentとは：概要、利点、クイックスタート、OpenClaw比較	NousResearch/hermes-agent	ツール呼び出しとタスク実行に対応するローカルAgentフレームワーク	ローカルAgentを動かしたい人
OpenHarness	OpenHarnessとは：オープンソースAgent Harnessでできること	HKUDS/OpenHarness	Agent HarnessとマルチAgent実行フレームワーク	Agent編成を研究する人
CodexBridge	Codexを中国系大模型に接続する：OpenAI互換APIとCodexBridge	begonia599/CodexBridge	CodexをOpenAI互換モデルAPIに接続	Codexを国内モデルにつなぎたい人
ccx	CCXでCodex向けOpenAI互換APIを一元管理する	BenedictKing/ccx	Claude、Codex、GeminiなどのAPI proxy管理	複数モデルを切り替える人
cc-haha	cc-haha：Claude Codeをデスクトップワークスペースにする	NanmiCoder/cc-haha	Claude Codeのデスクトップ作業台とComputer Use入口	GUIが好きなClaude Codeユーザー
DeepSeek-TUI	DeepSeek-TUI：DeepSeek V4をターミナルのコーディングAgentにする	Hmbown/DeepSeek-TUI	ターミナルでDeepSeekコーディングAgentを動かす	DeepSeekとCLIユーザー
Open Design	Open Design：Claude CodeとCodexをAIデザインツールにする	nexu-io/open-design	Claude Code / Codexをデザイン生成に参加させる	Agentでデザインプロトタイプを作りたい人
agentmemory	agentmemory：Claude Code、Codex、Cursorに永続メモリを追加する	rohitg00/agentmemory	Coding Agentに永続メモリを追加	長期プロジェクトを保守する開発者
Graphify	Graphify：コードベースをAIが問い合わせできる知識グラフにする	safishamsi/graphify	コードベースを知識グラフ化し、重複したファイル読込を減らす	大規模コードベースのユーザー
CC Switch	CC Switch：Claude Code、Codex、Gemini CLI、OpenClawをまとめて管理する	farion1231/cc-switch	複数AI CLIとアカウント/設定の切替管理	複数CLIを併用する人
Warp	Warpオープンソース化：ターミナルからAgentic Development Environmentへ	warpdotdev/warp	Agenticターミナルと開発環境	ターミナルをよく使う人
opencode	opencode、Claude Code、Codexの違い：オープンソースAIコーディングツールガイド	anomalyco/opencode	オープンソースAIコーディングAgent	Claude Code / Codex代替を探す人
9Router	9Router：Claude Code、Codex、Cursorを一つのAIルーターにつなぐ	decolua/9router	AIコーディングモデルのルーティングとtokenコスト制御	複数ツール、複数モデルのユーザー
goose	goose：デスクトップ、CLI、API一体のオープンソースAI Agent	aaif-goose/goose	デスクトップ、CLI、API対応のオープンソースAgent	汎用Agentワークスペースが欲しい人

Agentスキルとワークフロー

このカテゴリは、AI能力を再利用可能なスキル、プロセス、仕様に固定することに焦点を当てます。7 件のプロジェクトがあります。

プロジェクト	記事	GitHub	主な用途	向いている人
mattpocock/skills	Vibe Codingを拒否する：Matt PocockのskillsリポジトリがAIコーディングに工程制約を加える	mattpocock/skills	SkillsでAIコーディングの流れを制約する	Agentに工程規律を加えたい人
Superpowers	Superpowers：Coding Agentを工程フローに戻すスキルフレームワーク	obra/superpowers	Agentic skills frameworkと開発方法論	Coding Agentを体系的に使いたい人
Prompt-Vault	Prompt-Vault：AIコーディング能力を試すPrompt仕様ライブラリ	w512/Prompt-Vault	AIコーディング評価用prompt仕様を集める	モデル/ツール評価者
web-video-presentation	web-video-presentation：記事を録画可能なWeb動画にするAgent Skill	ConardLi/garden-skills	記事を録画可能なWeb動画へ変換	コンテンツ制作者と自動化ユーザー
nuwa-skill	nuwa-skill：「人を蒸留する」を実行可能フローにする	alchaincyf/nuwa-skill	人物の表現と思考フローをSkillで再現	スタイル型Agentを作る人
Scientific Agent Skills	Scientific Agent Skills：研究ワークフローをAI Agentに渡すスキル集	K-Dense-AI/scientific-agent-skills	科研ワークフロー向けSkill集	研究者、データ分析者、技術ライター
easy-vibe	easy-vibe：Vibe Coding初心者向け学習マップ	datawhalechina/easy-vibe	Vibe Coding入門マップ	AIコーディング初心者

RAG、ナレッジベース、メモリ

このカテゴリは、文書検索、ナレッジベース構築、長期メモリ、構造化抽出を扱います。7 件のプロジェクトがあります。

プロジェクト	記事	GitHub	主な用途	向いている人
LangExtract	Google LangExtract：LLMで長文から構造化データを抽出する	google/langextract	長文から構造化情報を抽出	情報抽出とデータ処理のユーザー
qmd	qmd：AI Agent向けローカルMarkdown文書検索	tobi/qmd	ローカルMarkdown文書検索	Markdownで知識管理する人
Firecrawl	Firecrawl：AI Agent向けWeb検索、クロール、操作API	firecrawl/firecrawl	Webクロール、検索、構造化データ入口	RAGとAgentデータ入口を作る人
RAGFlow	RAGFlow：オープンソースRAGエンジンの機能と使い方	infiniflow/ragflow	オープンソースRAGエンジン	企業ナレッジベースと文書Q&Aユーザー
OpenHuman	OpenHuman：オープンソース個人AI Agentのデスクトップ路線	tinyhumansai/openhuman	ローカル優先の個人AI Agentとメモリ層	個人データを統合したい人
OpenKB	OpenKB：文書を継続更新可能なLLMナレッジベースに編成する	VectifyAI/OpenKB	文書を更新可能なナレッジベースにする	文書ナレッジベースの保守者
PageIndex	PageIndex：ベクトルDBなしの推論型RAG文書索引	VectifyAI/PageIndex	ベクトルDBなしの推論型文書索引	新しいRAG手法に関心がある人

マルチモーダルとコンテンツ制作

このカテゴリは、画像、動画、文字起こし、コンテンツ配信を扱います。5 件のプロジェクトがあります。

プロジェクト	記事	GitHub	主な用途	向いている人
rembg	rembg：ローカル画像背景除去ツール	danielgatis/rembg	ローカル画像背景除去	EC、デザイン、画像処理ユーザー
awesome-gpt-image-2-prompts	GPT-Image 2プロンプト集：EC、ポスター、ポートレート、UI	EvoLinkAI/awesome-gpt-image-2-prompts	GPT-Image 2のプロンプトと事例集	AI画像生成とプロンプトユーザー
faster-whisper	faster-whisper：より速いWhisper文字起こしエンジン	SYSTRAN/faster-whisper	高性能speech-to-text	字幕、文字起こし、音声処理ユーザー
Pixelle-Video	Pixelle-Video：一つのテーマから短動画を生成するオープンソースAIエンジン	AIDC-AI/Pixelle-Video	テーマから短動画を生成するワークフロー	短動画とAIGC制作者
AiToEarn	投稿先が多すぎる？AiToEarnはAI Agentで制作者を助ける	yikart/AiToEarn	複数平台への配信と制作者自動化	コンテンツ運営者と制作者

ローカルモデルと推論

このカテゴリは、ローカルモデル実行と推論実験を扱います。現在は少なめで、1 件のプロジェクトがあります。

プロジェクト	記事	GitHub	主な用途	向いている人
ds4	DeepSeek 4をローカル実行：Apple Silicon MacでのAntirez ds4の試み	antirez/ds4	Apple SiliconでDeepSeek 4を試す	ローカルモデルと推論実験ユーザー

垂直アプリケーションと自動化

このカテゴリは、AgentやAI能力を金融、取引、ブラウザ、デスクトップ、EC監視などの具体的な場面に適用します。7 件のプロジェクトがあります。

プロジェクト	記事	GitHub	主な用途	向いている人
TradingAgents-CN	TradingAgents-CN：中国語ユーザー向けマルチAgent金融取引研究フレームワーク	hsliuping/TradingAgents-CN	マルチAgent金融取引研究フレームワーク	クオンツ、金融、Agent研究者
FinceptTerminal	FinceptTerminal：オープンソース金融端末、量化研究、AI Agentワークスペース	Fincept-Corporation/FinceptTerminal	金融端末、量化研究、AI Agent作業台	金融分析と量化ユーザー
Anthropic financial-services	Anthropic financial-services：金融Agentシナリオを再利用可能テンプレートにする	anthropics/financial-services	金融サービスAgentテンプレート	金融AI方案を作る人
ai-goofish-monitor	ai-goofish-monitor：AIでXianyu商品を自動監視するシステム	Usagi-org/ai-goofish-monitor	AI商品監視とXianyu自動化	中古取引監視ユーザー
CloakBrowser	CloakBrowser：PlaywrightとPuppeteer向けのより人間らしいブラウザ	CloakHQ/CloakBrowser	より人間らしいブラウザ自動化環境	ブラウザ自動化とAgent操作
UI-TARS-desktop	AIにPCを操作させる？UI-TARS-desktopがデスクトップ、ブラウザ、ツールを接続	bytedance/UI-TARS-desktop	デスクトップ、ブラウザ、ツール操作Agent	AIにPC操作を任せたい人
AI-Trader	AI-Traderとは：AI Agentが取引シグナルを出し、模擬取引する平台	HKUDS/AI-Trader	AI Agentの取引シグナルと模擬取引	金融Agentと取引研究者

AIアプリ開発基盤

このカテゴリは、AIアプリとAgentツールチェーン構築に必要な基盤コンポーネントを提供します。3 件のプロジェクトがあります。

プロジェクト	記事	GitHub	主な用途	向いている人
Prompt Optimizer	Prompt Optimizer：オープンソースのプロンプト最適化、テスト、MCPツール	linshenkx/prompt-optimizer	プロンプト最適化、テスト、MCPツール	Prompt engineeringとアプリ調整のユーザー
Playwright CLI	Playwright CLI入門：インストール、Skills、セッション、よく使うコマンド	microsoft/playwright-cli	coding agent向けブラウザ自動化CLI	ブラウザ操作が必要なAgentユーザー
Vercel AI SDK	Vercel AI SDKとは：TypeScript開発者向けAIアプリ統一ツールキット	vercel/ai	TypeScript AIアプリ開発SDK	フロントエンドとフルスタック開発者

Gemini 3.5 発表：Flash が先行し、Google は Agent と長時間タスク実行に重点

Wed, 20 May 2026 22:51:31 +0800

Google は 2026 年 5 月 20 日、Gemini 3.5 シリーズを正式に発表した。最初に利用可能になるのは Gemini 3.5 Flash で、単なるチャットモデルではなく、Agent、コード生成、長時間にわたる複雑なタスク実行を意識したモデルとして位置付けられている。

今回の発表から見える Google のメッセージは明確だ。Gemini 3.5 は質問に答えるだけでなく、計画し、実行し、結果を確認し、複数ステップのワークフローを継続的に進めることを目指している。

Gemini 3.5 Flash が先行

Gemini 3.5 Flash は、すでに複数のユーザー層に向けて提供されている。

一般ユーザーは Gemini アプリと Google 検索の AI Mode で利用できる。
開発者は Google Antigravity、Google AI Studio、Android Studio の Gemini API から利用できる。
企業ユーザーは Gemini Enterprise Agent Platform と Gemini Enterprise から利用できる。

Google は同時に、Gemini 3.5 Pro はまだ開発中で、すでに Google 内部で使われており、来月の提供を予定しているとも説明している。

つまり 3.5 シリーズでも Flash と Pro の役割分担は続く。Flash は速度、コスト、大規模実行を重視し、Pro はより複雑で高い能力を必要とする用途を担う可能性が高い。

焦点は Agent とコードタスク

Google は Gemini 3.5 Flash を、Agent とコーディング向けの最も強力なモデルの一つとして説明している。発表では、Terminal-Bench 2.1、GDPval-AA、MCP Atlas、CharXiv Reasoning などのコード・Agent 系ベンチマークで、Gemini 3.1 Pro の一部成績を上回ったとされている。

ただし、一般ユーザーにとって重要なのは個々のスコアではない。より大事なのは、Google がモデル能力を「実行可能なワークフロー」に寄せていることだ。コードを書くことに加えて、古いプロジェクトの移行、複雑なアプリ開発、財務レポートの整理、データ分析、継続的なテストまで扱おうとしている。

Antigravity の開発フレームワークでは、Gemini 3.5 Flash が複数の協調する subagents を使い、大きなタスクを処理できる。Google は AlphaZero の論文を解析して遊べるゲームを作る例、レガシーコードを Next.js に変換する例、都市景観や UI 案を並列生成する例を示している。

方向性ははっきりしている。AI コーディングツールは「コード片を生成する」段階から、「複数の Agent を組織してプロジェクトを進める」段階へ移りつつある。

マルチモーダル UI とグラフィック能力の強化

Gemini 3.5 Flash は Gemini 3 のマルチモーダル基盤を引き継いでいる。Google は、より豊かな Web UI、インタラクティブなアニメーション、視覚コンテンツを生成できると説明している。

発表で示された用途には次のようなものがある。

研究論文向けのインタラクティブなアニメーションを作る。
テキスト説明からインタラクティブなハードウェアモデルを生成する。
学校の募金活動向けにブランドコンセプト一式を作る。
短時間でチェックアウトフローの複数の UX 案を生成する。

これは開発者やプロダクトチームにとって意味が大きい。モデルは説明文を出すだけでなく、フロントエンドのプロトタイプ、インタラクション設計、可視化にも関わるようになる。

企業用途：時間のかかるワークフローを自動化する

Google は複数のパートナー事例も挙げている。Shopify は subagents で複雑なデータを分析し、販売者の成長予測に活用している。Macquarie Bank は 100 ページを超える複雑な文書を 3.5 Flash に読ませ、口座開設フローを高速化するテストをしている。Salesforce は Agentforce に統合し、Ramp は複雑な請求書 OCR の改善に使い、Xero は行政的なワークフローを AI Agent で処理し、Databricks はデータ異常の監視と修正提案に自動化ワークフローを使っている。

これらの事例は同じ方向を示している。企業での大規模モデル利用は、単発の Q&A からワークフロー自動化へ移っている。モデルが安価で速く、長時間のタスクで安定して動くかどうかは、単発の回答が見栄えよく見えるかどうかより重要になりつつある。

Gemini Spark：個人向け AI Agent

Google は Gemini Spark も発表した。Gemini 3.5 Flash によって動く個人向け AI Agent で、ユーザーの指示のもとで長時間動作し、能動的にタスクを実行することを目指している。

Gemini Spark は信頼されたテスター向けに展開が始まっており、Google は来週、米国の Google AI Ultra 加入者向けに Beta を開放する予定だ。

ここは注目に値する。Google 検索、Gemini アプリ、Android、Workspace、ブラウザ関連のエコシステムは、すでに個人のデジタル生活の多くに接点を持っている。個人向け Agent がこれらの入口と結び付くなら、単独のチャットボットより大きな影響を持つ可能性がある。

安全対策も前段に移る

Google は Gemini 3.5 を Frontier Safety Framework に基づいて開発し、情報セキュリティや CBRN 関連リスクへの防護を強化したとしている。さらに、モデルが回答する前に推論過程の確認と理解を助ける interpretability tools にも触れている。

これは、最前線のモデル発表が能力競争だけではなくなっていることを示している。Agent、自動実行、長時間タスクを強調するほど、安全制御、誤拒否率、有害出力の抑制、解釈可能性は重要になる。

Gemini 3.5 をどう見るか

Gemini 3.5 Flash の意味は、単なる新モデル発表ではない。Google が次の AI プロダクトの形に賭けているように見える。つまり、ツールを呼び出し、タスクを分割し、協調して実行し、UI を生成し、個人と企業のワークフローに入っていくモデルだ。

開発者にとっては、Google Antigravity、AI Studio、Gemini API、Android Studio での実際の体験が重要になる。企業にとっては、benchmark だけでなく、実際の業務フローで手作業を安定して減らせるかが焦点になる。

Gemini 3.5 Pro はまだ正式公開されていない。Pro が出たあと、Flash と Pro の能力、価格、速度、コンテキスト処理の違いが、それぞれに適した本番用途を決めることになる。

参考:

Google Blog: Gemini 3.5

agentmemory：Claude Code、Codex、Cursorに永続メモリを持たせる

Tue, 19 May 2026 10:56:50 +0800

rohitg00/agentmemory は、AIコーディングAgent向けの永続メモリシステムです。目的は明確で、Claude Code、Codex CLI、Cursor、Gemini CLI、OpenCode などのツールが、新しいセッションのたびにプロジェクト背景、アーキテクチャ判断、過去の問題を学び直さなくて済むようにすることです。

プロジェクトURL：https://github.com/rohitg00/agentmemory

執筆時点では、GitHub API上で約1.3万 star、主要言語は TypeScript、ライセンスは Apache-2.0 でした。READMEでは “Persistent memory for AI coding agents” と説明されています。

何を解決するのか

AIコーディングAgentのよくある課題は、記憶がセッションごとに切れることです。今日Agentに認証の問題を修正させても、明日新しい会話を開くと、次のような情報を忘れていることがあります。

なぜその設計判断をしたのか。
どのファイルを慎重に扱うべきか。
以前どのバグを直したのか。
どのコマンド、ツール、ローカルサービスを使うのか。
チームのコーディング規約は何か。

静的なメモも役立ちますが、実際の作業フローとつながらず忘れられがちです。agentmemory は、複数のAIコーディングツールで共有できるメモリ層を提供しようとしています。

対応するAgent

READMEでは、Claude Code、Codex CLI、Cursor、Gemini CLI、OpenCode、その他 MCP 対応ツールが挙げられています。ローカルサービス、MCP、hooks、連携機能を通じて、複数のアシスタントが同じプロジェクト文脈を共有する考え方です。

ツールを切り替えるチームでは特に便利です。ある開発者は Cursor、別の開発者は Claude Code、自動化は Codex CLI という状況でも、共有メモリがあれば説明の繰り返しを減らせます。

クイックスタート

グローバルインストール：

npm install -g @agentmemory/agentmemory
agentmemory
agentmemory demo
agentmemory connect claude-code

npx でも実行できます。

`1`	`npx @agentmemory/agentmemory`

ローカルサービスは次で利用できます。

`1`	`http://localhost:3113`

実際には、まずメモリサービスを起動し、コーディングアシスタントを接続して、開発中にAgentがプロジェクトメモリを読み書きする流れになります。

静的なメモリファイルとの違い

多くのチームはすでに AGENTS.md、CLAUDE.md、README、ローカルドキュメントを持っています。これらは便利ですが静的です。セッション履歴、タスク結果、繰り返し出てくる判断を自動的に扱うわけではありません。

agentmemory は永続的な文脈サービスに近いものです。現在のプロジェクトやタスクに関係するメモリを保存し、必要なときに取り出すことを目指しています。ドキュメントを置き換えるというより、作業文脈を再利用しやすくする役割です。

典型的な用途

たとえば次のような場面で役立ちます。

プロジェクトのセットアップ手順やよく使うコマンドを覚える。
リスクのあるリファクタを避けた理由を記録する。
flaky test やローカルサービスについてメモする。
ドメイン用語を複数のAIアシスタントで共有する。
新しいセッションでも前回の作業を続けやすくする。

長期運用のプロダクト、モノレポ、暗黙知の多いプロジェクトでは特に価値があります。

注意点

まず、メモリの品質が重要です。古い情報や間違った情報が残ると、将来のAgentが同じ誤りを繰り返す可能性があります。重要なメモリは短く、明確で、レビューしやすく保つべきです。

次に、プライバシーです。セキュリティモデルが明確でない限り、秘密情報、APIキー、顧客データ、本番環境の機密情報を保存すべきではありません。

最後に、メモリはテストの代わりにはなりません。文脈理解は助けますが、最終的な保証はコードレビュー、テスト、検証から得る必要があります。

向いている人

agentmemory は、複数のAIコーディングツールを使う開発者、大きなコードベースを扱うチーム、Agentに前回の作業を継続させたいユーザーに向いています。小さな単発スクリプトでは必須ではありません。

まとめ

agentmemory が面白いのは、メモリを小さなプロンプト技ではなく、AIコーディングのインフラとして扱っている点です。コーディングAgentが日常開発に入ってくるほど、永続的なプロジェクトメモリは現実的な不足ピースになります。

Gemini 3.5 Pro がリーク：コードネームは Cappuccino、Google はコーディングと Agent で巻き返しを狙う

Sun, 17 May 2026 11:47:27 +0800

Google はまだ Gemini 3.5 Pro を正式発表していません。

現時点で見えている情報は、主に開発者コミュニティのスクリーンショット、匿名ベンチマーク、リーカーの投稿、メディアの報道に基づいています。36Kr / 新智元は 2026 年 5 月 15 日、次世代 Gemini のチェックポイントが社内で Cappuccino と呼ばれている可能性があり、関連モデルがコミュニティや評価プラットフォームで先に露出していると整理しました。

これらの情報は公式発表と同一視すべきではありません。ただし、方向性ははっきりしています。Google は、コーディングと推論能力、そして常時稼働する AI Agent という 2 つの弱点を同時に補おうとしています。

まず結論

今回のリークは 3 層に分けて見ると分かりやすいです。

Gemini 3.5 Pro はまだ正式発表されておらず、Cappuccino は内部チェックポイントまたは候補版のコードネームに近いものです。
露出した情報では、新しい Gemini はコード生成、SVG / インタラクティブ Web 生成、マルチモーダル出力で改善しているようです。
Google が並行してテストしている Gemini Spark は、モデルそのもの以上に重要かもしれません。24 時間稼働する個人向け AI Agent を示しているからです。

つまり、これは単なる「モデルのベンチマークニュース」ではありません。Google I/O を前にしたプロダクトロードマップのシグナルに近く、モデルは GPT-5.5 に追いつき、Agent はユーザーのワークフロー入口を押さえにいく構図です。

Cappuccino とは何か

36Kr の記事によると、Lentils の投稿では、Cappuccino というコードネームの Gemini 3.5 Pro チェックポイントが生成され始めているとされています。数時間前までコミュニティでは Gemini 3.2 が話題でしたが、最新リークでは一気に 3.5 へ飛びました。

この命名が最終的に正しければ、Google は次の Gemini を通常の小幅更新ではなく、より大きなバージョンジャンプとして見せたいのかもしれません。

ただし現時点では、Cappuccino はあくまでリーク上の内部コードネームとして扱うべきです。Google が正式モデルを公開済みという意味ではなく、最終的なリリース名が必ず Gemini 3.5 Pro になるとも限りません。

なぜコーディング能力が焦点なのか

今回のリークで最も注目されているのは、新しい Gemini のコーディング能力です。

36Kr が引用したコミュニティのスクリーンショットやベンチマーク情報によると、新モデルは次のタスクで強化されているようです。

SVG とビジュアルコンポーネントの生成。
インタラクティブ Web アプリの生成。
アニメーション、3D、調整可能なパラメータパネルなど複雑なフロントエンド出力。
論理推論とコード生成の改善。

記事ではさらに、Abacus.AI CEO の Bindu Reddy が、3.2 Flash はコーディングと推論で GPT-5.5 に近い水準に達しつつ、コストは低いと述べたことも紹介しています。一方、別のメディア筋は、新しい Gemini の総合性能はおおむね GPT-5.5 クラスだが、質的な飛躍とまでは言えないと見ているようです。

そのため、「GPT-5.5 に追いついた」という表現は慎重に読む必要があります。これは Google 公式のベンチマーク結果ではなく、複数のリークや匿名評価に基づく相対的な判断に近いものです。

Google がコーディングを急ぐ理由

AI コーディングは、開発者ツールから基盤モデル競争の中心へ移りました。

OpenAI には Codex があり、Anthropic には Claude Code があります。これらはエンジニアだけでなく、プロダクトマネージャー、デザイナー、運用担当者を「自然言語から動くプロダクトを作る」ワークフローへ連れてきています。

一方で Google には Gemini と Antigravity がありますが、開発者の意識の中で同じ強さのデフォルト入口にはなっていません。36Kr の記事でも、Antigravity は外部市場でまだ本格的に突破できておらず、価格、利用枠通知、体験の安定性についてコミュニティで議論が続いていると触れられています。

だからこそ、新しい Gemini が自分を証明するなら、コーディングが最も直接的な戦場になります。問われるのは「コードを書けるか」だけではありません。完全な UI を安定して生成できるか、複雑な要件を理解できるか、ツールを呼び出せるか、エラーを修正できるか、実際の開発フローに溶け込めるかです。

Spark は 3.5 Pro より重要かもしれない

同じリークの流れで、Gemini Spark BETA も見つかりました。

TestingCatalog などの情報によると、Spark の位置付けは「常時稼働 AI Agent」に近いものです。受信箱を処理し、オンラインタスクを実行し、複数ステップのワークフローを管理し、Google アプリ、スキルモジュール、チャット履歴、定期タスク、ログイン済みサイト、位置情報などのコンテキストに接続します。

これは Spark が通常のチャット入口ではないことを意味します。長時間オンラインで動き続け、コンテキストを読み続け、ユーザーの代わりにタスクを実行するシステムになり得ます。

魅力は明らかです。Google が Gmail、Calendar、Chrome、Android、Workspace、Gemini をつなげられれば、Spark は OpenAI や Anthropic が簡単には再現できない配布面の優位を持ちます。

同時にリスクも明らかです。36Kr の記事では、Spark 関連の説明に「確認なしに情報を共有したり購入を完了したりする可能性がある」という趣旨の表現があったと紹介されています。センシティブな操作の前に許可を求める設計だとしても、この種の Agent はプライバシー、権限境界、誤操作のリスクを生みます。

一般ユーザーにとっての意味

普通の Gemini ユーザーにとって、今回本当に注目すべきなのはモデル名ではなく、次の 3 つの変化です。

第一に、Google は「完成した結果を生成する」能力をさらに強化する可能性があります。これまで Gemini は、ビジュアル生成、SVG、フロントエンドページで手抜きに見える出力をするという不満がありました。新モデルが一度に複数の完成度の高い案を出せるなら、体験はかなり改善します。

第二に、コーディング能力はより軽量なモデルへ下りていく可能性があります。リークでは Flash 版のコーディング、推論、インタラクティブ生成の改善が繰り返し語られており、将来は複雑なタスクに必ずしも Pro モデルが必要ではなくなるかもしれません。

第三に、Agent はより能動的になります。Spark が公開されれば、Gemini は質問に答えるだけではなく、メール、Web、購入、予定、アプリ横断タスクを長期的に引き受け始める可能性があります。

効率面では良い知らせですが、権限管理には新しい課題が生まれます。

開発者にとっての意味

開発者は 2 つの点を注視すべきです。

1 つ目はツールエコシステムです。36Kr の記事では、コミュニティがモデル選択画面に MCP Tool Testing のような未公開入口を見つけたとされています。Gemini が MCP やサードパーティツールテストをネイティブにサポートするなら、開発者自身のツールチェーンに接続しやすくなります。

2 つ目はコストと安定性です。新しい Gemini が一部ベンチマークで GPT-5.5 に追いついたとしても、開発者が最終的に見るのは実際のコード品質、コンテキストの安定性、価格と利用枠が予測可能かどうかです。

過去 1 年の AI コーディングツール競争が示したのは、モデル能力は入場券にすぎないということです。開発者を残すのは、日常プロジェクトで安定してコードを修正し、テストを走らせ、コンテキストを読み、境界条件を扱えるかどうかです。

今このニュースをどう読むべきか

このニュースは「強いシグナル、弱い確認」として読むのが適切です。

強いシグナルは、複数のコミュニティ上の手がかりが、Google がより強い新 Gemini と、より能動的な Gemini Spark Agent を準備していることを示している点です。

弱い確認は、Gemini 3.5 Pro がまだ公式発表されておらず、Cappuccino もリーク上のコードネームにとどまり、「GPT-5.5 に追いついた」という主張も Google 公式ベンチマーク、第三者評価、実ユーザーの検証を待つ必要がある点です。

現時点で最も安全な見方は次の通りです。

すでに公開された製品として扱わない。
Google の次段階の Gemini 路線を示す早期予告として見る。
I/O または今後の公式イベントで、モデル名、API 提供、価格、コンテキストウィンドウ、ツール呼び出し、Agent の権限境界が確認されるかに注目する。

まとめ

Gemini 3.5 Pro / Cappuccino の露出は、Google が次世代 Gemini をより強く押し出そうとしている可能性を示しています。補おうとしているのは単一の能力ではなく、AI ワークフロー全体です。モデルはコードを書き、UI を生成し、複雑な推論を処理する必要があり、Spark は Gemini を常時稼働 Agent へ押し出します。

ただし公式発表前は、すべてのベンチマークやスクリーンショットは手がかりにすぎません。Gemini 3.5 Pro が巻き返せるかを決めるのは、コードネームの響きではなく、実際の開発、実際のオフィス業務、実際の複数ステップタスクで安定して勝てるかどうかです。

参考リンク：

Codex が ChatGPT モバイルからのリモートアクセスに対応、Enterprise ワークスペースで Access Tokens が利用可能に

Sun, 17 May 2026 09:12:07 +0800

OpenAI は 2026 年 5 月 14 日、ChatGPT Enterprise & Edu Release Notes を更新し、Codex に関する 2 つの変更を発表しました。Codex が ChatGPT モバイルアプリからのリモートアクセスに対応し、Enterprise ワークスペースで Codex access tokens を使った制御された自動化が可能になりました。

これはモデル能力の発表ではありません。Codex という製品の形が変わりつつあるという話です。Codex は、ローカル環境や Web セッション内の coding assistant から、長時間実行でき、遠隔から管理でき、企業の自動化ワークフローに接続できる coding agent へ近づいています。

今回の更新内容

OpenAI Help Center によると、Codex は ChatGPT mobile app からのリモートアクセスに対応しました。ユーザーはスマートフォンから実行中の Codex 環境に接続し、長時間タスクを追跡し、必要なタイミングで介入できます。

同時に、ChatGPT Enterprise ワークスペースでは Codex access tokens が利用可能になりました。これは信頼された非対話型のローカルワークフロー向けで、毎回ブラウザでログインしなくても、ChatGPT workspace identity と企業側の制御を使って自動化を実行できます。

今回の更新は、次の 2 つの入口として理解できます。

モバイルリモートアクセス：Codex が長時間タスクを実行しているとき、ユーザーが PC の前にいない問題を解決する。
Access Tokens：企業の自動化スクリプトが制御された ID で Codex ワークフローを使えるようにする。

モバイルリモートアクセスが解決する問題

Codex のタスクは、いつも数秒で終わるわけではありません。実際の開発では、リポジトリを読み、複数ファイルを変更し、テストを実行し、コマンド出力を待ち、エラーに応じて修正を続け、途中でユーザーの承認を求めることがあります。

これまでは、こうしたタスクではユーザーがローカル Mac、デスクトップアプリ、CLI、IDE の近くにいる必要がありました。今後は ChatGPT モバイルアプリがリモートコンソールになり、PC から離れていても Codex を追跡できます。

OpenAI は、モバイル側で基盤環境のリアルタイム状態を確認できると説明しています。対象には次が含まれます。

プロジェクトコンテキスト。
approvals。
screenshots。
terminal output。
diffs。
test results。

ユーザーはスマートフォンから Codex の質問に答え、実行をリダイレクトし、操作を承認し、出力を確認し、複数の connected hosts を切り替えられます。基盤タスクは Mac host や接続されたリモート環境で動き続け、スマートフォンは確認と制御のために使われます。

開発者にとっての価値

この機能は、長時間実行され、途中確認が必要な開発タスクに特に向いています。

たとえば：

Codex が時間のかかるテストを実行していて、外出中に結果を確認したい。
Codex が複数ファイルを変更し、スマートフォンで diff を見てから次のステップを承認したい。
Codex が危険な操作の前で確認待ちになっており、遠隔で処理したい。
ローカル Mac に複数の connected hosts があり、スマートフォンで状態を切り替えて見たい。

価値はスマートフォンでコードを書くことではありません。ずっと PC の前にいる必要がなくなることです。Codex は元の環境で作業を続け、ユーザーは重要な節目だけ介入します。

これは Codex が「バックグラウンド Agent」に近づいていることも示しています。タスクは継続実行でき、ユーザーが常時オンラインでなくてもよい一方、承認と制御は人間側に残ります。

Access Tokens が解決する問題

Codex access tokens は ChatGPT Enterprise ワークスペース向けです。重点は個人ユーザーの通常ログインではなく、企業内の信頼された自動化です。

企業には、非対話的に実行したいローカルまたは内部ワークフローがよくあります。

定期的なコードチェック。
管理されたマシン上での Codex ワークフロー起動。
Codex と社内開発ツールチェーンの接続。
ブラウザを開かずにワークスペース ID を使うこと。

Access tokens により、これらのワークフローは ChatGPT workspace identity を持って実行され、同時に企業ポリシーの制御を受けます。一時的な手動ログインより自動化に向いており、個人資格情報の共有よりガバナンスに載せやすい仕組みです。

普通の API key ではない

この点は重要です。Codex access tokens は、単なる万能 API key と理解すべきではありません。

OpenAI の説明では、access tokens は ChatGPT Enterprise ワークスペースで利用でき、管理者はワークスペースレベルの可用性を管理でき、許可されたロールを持つメンバーは自分の tokens を作成できます。利用可能な場合、ガバナンス画面にも access token の活動が反映されます。

つまり、access tokens は企業の権限、ロール、監査フレームワーク内に置かれています。

管理者がワークスペースで有効にするかを決められる。
すべてのメンバーが当然作成できるわけではない。
token の活動はガバナンスビューに入る可能性がある。
ChatGPT workspace identity と企業側の制御を継承する。

個人が長期秘密鍵を気軽に作成するのとは違います。

安全な初期設定：Remote Control はデフォルトでオフ

Codex mobile remote access は、コード環境、ターミナル出力、diff、テスト結果、操作承認に関わります。デフォルトで有効なら、企業にとって明確なセキュリティリスクになります。

そのため OpenAI の初期設定は保守的です。remote control はデフォルトでオフで、管理者または owner が Workspace settings で有効にする必要があります。

モバイルリモートアクセスの有効化には、次の要素が関係する場合があります。

workspace-enabled Remote Control access。
SSO。
多要素認証。
passkey。

これは、アプリを更新したら全員が自動的に使える機能ではなく、企業の IT とセキュリティチームが設定すべき機能です。

利用前に必要な更新

OpenAI は、モバイルリモートアクセスを使うには両側の更新が必要だと説明しています。

ChatGPT mobile app。
macOS 上の Codex app。

ワークスペース側の要件によっては、セットアップ時に SSO、多要素認証、passkey フローが発生することもあります。

実際に導入する場合、企業管理者はまず Workspace settings の remote control 設定と、どのメンバーまたはロールに利用を許可するかを確認する必要があります。

企業での Codex 利用への影響

今回の更新は、Codex を 2 つの方向へ進めます。

第一に、Codex は長時間タスクに向きます。以前は長時間タスクではユーザーがずっと見ている必要がありましたが、今後はスマートフォンで状態を確認し、操作を承認できるため、Codex をバックグラウンドで動かしやすくなります。

第二に、Codex は企業自動化に向きます。Access tokens により、非対話型ワークフローに正式な ID 経路ができ、内部 CI、コードレビュー、スクリプト、開発プラットフォームとの接続がしやすくなります。

この 2 つを合わせると、Codex は単なる開発者の手元の AI 助手ではなく、企業の開発フローに組み込まれる管理可能な agent へ近づいています。

注意すべき境界

今回の更新は便利ですが、Codex を完全に無人で任せてよいという意味ではありません。

企業利用では、引き続き次の点に注意が必要です。

どのプロジェクトでリモート制御を許可するか。
どのコマンドに承認が必要か。
token をどう作成、ローテーション、失効するか。
mobile remote access が社内のデバイス管理ポリシーに合うか。
ターミナル出力、スクリーンショット、diff に機密情報が含まれないか。
監査ログとガバナンス画面が社内コンプライアンス要件を満たすか。

特に access tokens は、自動化フローに入った時点で他の企業資格情報と同じように扱うべきです。最小権限、定期的なローテーション、ハードコード回避、不要 token の速やかな失効が必要です。

まとめ

今回の OpenAI Codex 更新は焦点が明確です。ChatGPT モバイルから Codex の長時間タスクにリモートアクセスでき、Enterprise ワークスペースでは Codex access tokens による制御された自動化が可能になりました。

前者は、開発者がずっと PC の前にいる必要を減らします。後者は、企業が Codex をより正式に社内ワークフローへ接続できるようにします。両者を合わせると、Codex は対話型 coding assistant から、遠隔管理、監査、自動化接続に向いた企業向け coding agent へ進んでいることが分かります。

参考リンク：

OpenAI Help Center：ChatGPT Enterprise & Edu - Release Notes

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は保存しておきたい出発点です。

DeepSeek-TUI：DeepSeek V4をターミナル上のコーディングAgentにする

Sat, 16 May 2026 22:41:41 +0800

DeepSeek-TUI は、DeepSeek V4をターミナル開発フローに接続するオープンソースプロジェクトです。単なるチャットの外枠ではありません。Claude CodeやCodex CLIに近い「コマンドラインのコーディングAgent」であり、ファイルを読み、コードを編集し、コマンドを実行し、ツールを呼び出し、TUI上でタスクを継続的に進められます。

すでにエディタとターミナルを行き来している開発者にとって、この種のツールの価値は分かりやすいものです。コードをWebチャットへ何度もコピーする必要がなく、プロジェクト構造を毎回手で説明する必要もありません。タスクを渡せば、現在のワークスペースからコンテキストを読み取り、手順を計画し、変更を実行し、結果をレビュー用に返してくれます。

DeepSeekの利用入口を補う

DeepSeekモデル自体は強い推論能力とコード能力を持っています。ただし、その能力を実際の開発フローに落とし込むには、工程化された外側のレイヤーが必要です。

Webチャットは質問には向いていますが、長時間のプロジェクト編集には向いていません。APIはシステム連携には向いていますが、個人開発者はツール呼び出し、コンテキスト管理、ファイル操作、権限制御を自分で組む必要があります。DeepSeek-TUIが補おうとしているのはこの層です。DeepSeek V4を、ターミナル内で働けるAgentとして包みます。

プロジェクト説明によると、主な機能は次の通りです。

ターミナルTUI;
DeepSeek V4向けの会話とタスク実行;
ツール呼び出しとファイル操作;
1Mコンテキスト対応;
Autoモード;
サブAgent;
サンドボックス実行;
永続タスクキュー。

これらの機能の目的は、モデルの返答をより人間らしくすることではありません。モデルを開発現場に入りやすくすることです。

長いタスクには純粋なCLIよりTUIが向いている

多くのAI CLIツールは、最初はプレーンテキストの対話から始まります。プロンプトを入力し、出力を待ち、コマンドをコピーしたり追加コンテキストを渡したりする方式です。これは単純ですが、タスクが長くなるとすぐ混乱します。

TUIの利点は、会話、ファイル、実行結果、タスク状態をより安定した画面に置けることです。コーディングAgentではこれが重要です。1つのコードタスクは、単なる一問一答ではないからです。多くの場合、次の流れを含みます。

プロジェクト構造を理解する。
関連ファイルを探す。
コードを変更する。
テストやコマンドを実行する。
エラーに基づいて修正を続ける。
変更内容をまとめる。

画面がログの羅列だけだと、ユーザーはAgentが今どこまで進んだのかを判断しにくくなります。TUIは少なくとも、観察し、必要なら引き継ぐための入口を提供します。

Autoモードは境界が明確なタスクに向く

DeepSeek-TUIが言及しているAutoモードは、境界が比較的明確な作業に向いています。たとえば小さなバグ修正、スクリプト追加、設定変更、文書整理、局所的な機能実装です。

こうしたタスクには共通点があります。目標が明確で、確認方法も明確で、影響範囲が制御できます。Agentは自分でファイルを調べ、編集し、コマンドを実行し、結果をユーザー確認に戻せます。

ただし、Autoモードは無制限の権限ではありません。実際のプロジェクトでは、ファイル削除、大規模リファクタリング、データベース移行、デプロイコマンドには明確な確認が必要です。コーディングAgentの効率は自動化から生まれますが、リスクも同じ場所から生まれます。コマンドを実行できるツールほど、サンドボックス、権限境界、人間によるレビューが必要です。

サブAgentの意味はタスク分割にある

サブAgentは新しい概念ではありませんが、コード作業では役に立ちます。

少し複雑なタスクでは、複数の種類の作業が同時に必要になります。コードを読む役、実装を変更する役、テストを確認する役、ドキュメントを整理する役です。従来のマルチAgentシステムが派手に見えるだけで終わりがちなのは、実際のツールやワークスペースを持たず、会話の中で相談しているだけだからです。

サブAgentがファイルシステム、コマンド実行、タスクキューと結びつけば、より現実的なタスク分割の仕組みになります。たとえば、あるサブAgentが依存関係を分析し、別のサブAgentが特定モジュールを変更し、メインAgentが結果を統合する、といった形です。これにより、1つのコンテキストに無関係な情報を詰め込みすぎる問題を減らせます。

もちろん、サブAgentには追加コストもあります。token消費、複雑な状態、追跡しにくい責任境界です。そのため、中程度以上の複雑さを持つタスクに向いており、すべての小さな修正に必要なものではありません。

1Mコンテキストは万能ではないが、プロジェクト理解には役立つ

1Mコンテキストは大げさに聞こえますが、コーディングでは単なる宣伝文句ではありません。

実際のコードベースのコンテキストは細かく分散しています。README、設定ファイル、型定義、テスト、呼び出しチェーン、過去の約束事、エラーログは、どれも1つの修正に影響します。長いコンテキストは、局所だけを見て手を動かす問題を減らし、モデルがより多くのプロジェクト制約を保持する助けになります。

ただし、コンテキストが長いことは判断が正しいことと同義ではありません。コードタスクには依然として検索、選別、検証が必要です。プロジェクト全体をコンテキストに詰め込むことが、関連ファイルを正確に読むことより良いとは限りません。良いコーディングAgentは、長いコンテキストをバッファとして使うべきであり、エンジニアリング判断の代替にすべきではありません。

向いているユーザー

DeepSeek-TUIは次のような人に向いています。

ターミナルでDeepSeekを使ってコード作業をしたい開発者。
ツール呼び出しやファイル操作の枠組みを自分で作りたくない人。
Claude CodeやCodex CLIに慣れており、DeepSeekモデルの入口も試したい人。
Web上のコード断片ではなく、ローカルプロジェクトのコンテキストが必要な人。
AIコーディングの流れをコマンドライン環境に入れたい人。

たまに関数の書き方を聞くだけなら、Webチャットで十分です。モデルに直接プロジェクト変更へ参加してほしいなら、ターミナルAgentの意味が大きくなります。

注意すべきリスク

この種のツールで特に注意すべきことは3つあります。

1つ目は権限です。ツールがファイルを読み書きし、コマンドを実行できるなら、デフォルトでどこにアクセスできるのか、ファイルを削除できるのか、ネットワークに出られるのか、危険なコマンドに確認が必要なのかを把握する必要があります。

2つ目はロールバックです。使う前にGitの作業ツリーをきれいにしておくと、Agentの変更を毎回 git diff で明確に確認できます。未コミットの変更が大量にある状態で、Agentに自動編集させるべきではありません。

3つ目は検証です。Agentがコードを書いたことは、タスク完了を意味しません。テスト、ビルド、lint、人間のreviewは残す必要があります。AIコーディングツールは進行を速めますが、最後のエンジニアリング確認を置き換えるものではありません。

まとめ

DeepSeek-TUIの意味は、また1つチャットクライアントが増えたことではありません。DeepSeek V4を、実際の開発作業に近いターミナル環境へ入れていることです。

開発者にとって、モデル能力は最初の一歩にすぎません。本当に体験を左右するのは、プロジェクトを読めるか、安全にファイルを変更できるか、検証コマンドを実行できるか、長いタスクで状態を保てるか、ユーザーがいつでも引き継げるかです。

DeepSeekを日常的なコード変更、プロジェクト読解、自動化された開発タスクに使いたいなら、DeepSeek-TUIは注目に値します。方向性も明確です。AIコーディングツールは「コードの質問に答える」段階から「プロジェクト実行に参加する」段階へ進んでいます。

API Key を GitHub に push しないために：AI コーディング時代のシークレット漏洩対策

Sat, 16 May 2026 16:26:50 +0800

AI によるコーディングは、ソフトウェアを作り始めるハードルを大きく下げました。一方で、これまで主に開発チーム内で起きていたセキュリティ問題が、初心者や非エンジニアにも直接降りかかるようになっています。

よくある事故は、API Key、Secret、Token、データベース接続文字列、.env 設定ファイルを公開リポジトリに push してしまうことです。ローカルでは「アプリを動かすための設定」に見えても、GitHub の公開リポジトリに入った瞬間、自動スキャン、自動呼び出し、自動悪用の対象になります。

シークレット漏洩は珍しい事故ではありません。GitGuardian の 2026 年レポートでは、2025 年の公開 GitHub コミットに約 2865 万件の新しいハードコードされた認証情報が含まれ、AI サービス関連の認証情報漏洩は前年比 81% 増加したとされています。これは単なる不注意ではなく、AI コーディング、素早いプロトタイピング、公開ホスティングが重なって規模を拡大している問題です。

初心者が Key を漏らしやすい理由

多くの AI Agent や小さなツールには、ローカルディスク上の「リポジトリ」と、GitHub 上で世界中から見える「リポジトリ」があります。初心者はこの境界を意識できないことがあります。

ローカル実行時には、config.json、.env、settings.yaml に API Key を入れていても、単なる開発用設定に見えます。しかし git add .、git commit、git push を実行すると、それらのファイルがそのままアップロードされる可能性があります。公開されたリポジトリでは、スキャンボットはビジネスロジックを理解する必要がありません。シークレットらしい形式を見つければ十分です。

AI コーディングはこの問題をさらに広げます。

AI が生成するサンプルコードに OPENAI_API_KEY = "sk-..." のような書き方が入ることがある。
初心者は「まず動かす」ために、フロントエンド、スクリプト、設定ファイルへ直接 Key を書きがち。
多くの vibe coding プラットフォームは、GitHub の Push Protection を通らずに直接デプロイできる。
ユーザーは AI が生成したプロジェクト内のファイル、API、既定権限を把握していないことがある。

AI は動くものを速く作る手助けをしますが、セキュリティ責任まで自動で引き受けてはくれません。

`.gitignore` は飾りではない

Git はバージョン管理を行い、GitHub はコードをホストします。.gitignore は、どのファイルを履歴に入れないかを Git に伝えるためのファイルです。

基本的な AI プロジェクトでは、少なくとも次を除外すべきです。

.env
.env.*
*.key
*.pem
config.local.*
secrets.*
credentials.*

ただし .gitignore だけでは不十分です。これは未追跡ファイルが今後追加されるのを防ぐだけです。すでにコミットされたシークレットファイルは、後から .gitignore に書いても履歴から消えません。

安全な習慣は次の通りです。

新規プロジェクトの最初に .gitignore を作る。
API Key は環境変数またはローカル設定だけに置く。
.env.example にはプレースホルダーだけを書き、本物の Key は書かない。
コミット前に gitleaks、trufflehog、GitHub Secret Scanning などでスキャンする。

Key を push したら、ファイル削除だけでは安全にならない

Key を公開リポジトリへ push してしまった場合、最初にやるべきことは「ファイルを消してもう一度コミットする」ことではありません。まず Key を失効またはローテーションします。

Git は履歴を記録します。最新コミットでファイルを削除しても、古いコミット、fork、clone、キャッシュ、スキャンシステムに内容が残る可能性があります。GitHub の公式ドキュメントでも、パスワード、Token、認証情報が漏れた場合は、まず取り消しまたはローテーションすることを勧めています。

推奨手順は次の通りです。

サービス提供元の管理画面で古い Key を失効し、新しい Key を発行する。
請求、利用ログ、不審な IP、異常な使用量を確認する。
ハードコードされた Key を消し、環境変数またはシークレット管理サービスへ移す。
git filter-repo または BFG でリポジトリ履歴から機密ファイルを除去する。
GitHub Secret Scanning と Push Protection を有効にする。
CI/CD、デプロイ基盤、クラウド関数、フロントエンド成果物に古い Key が残っていないか確認する。

OpenAI、Anthropic、DeepSeek、クラウド事業者、決済、メール、データベースなどの Key が漏れると、課金被害だけでなく、データ読み取り、サービス悪用、サプライチェーン汚染、業務アカウント停止につながる可能性があります。

フロントエンドに本物の Key を置いてはいけない

初心者は「画面が動けばよい」と考えて、API Key をフロントエンド JavaScript に書いてしまうことがあります。

`1`	`const apiKey = "sk-xxxxxxxx";`

これはほぼ公開と同じです。ブラウザ上のコード、ネットワークリクエスト、Source Map、ビルド成果物は確認できます。秘密にすべき Key はクライアント側に出してはいけません。

正しい構成は、フロントエンドから自分のバックエンド API を呼び、バックエンドが環境変数を読んで外部 API を呼ぶ形です。

// frontend
await fetch("/api/chat", {
  method: "POST",
  body: JSON.stringify({ message })
});

サーバー側で環境変数を使います。

1
2

// server
const apiKey = process.env.OPENAI_API_KEY;

これは形式の問題ではなく、Key をサーバー環境に残し、ページ訪問者全員へ露出しないための設計です。

Vibe Coding でも安全責任は消えない

vibe coding の問題は GitHub 漏洩だけではありません。AI コーディングプラットフォームから直接公開インターネットへデプロイされるアプリも多く、従来のコードレビュー、リポジトリスキャン、セキュリティテストを通らないことがあります。

RedAccess の最近の調査では、AI コーディングツールで生成またはホストされた公開資産が大量に見つかり、その一部が企業データ、個人情報、内部ファイルを露出していました。ここでの教訓は単純です。「公開できる」が簡単になりすぎると、「公開すべきか」「社内限定にすべきか」「権限制御があるか」が見落とされやすくなります。

AI で生成したアプリを公開する前に、少なくとも次を確認します。

このアプリは本当に公開アクセスが必要か。
ログイン、認証、権限分離があるか。
データベース、API Key、Token、Webhook URL がフロントエンドに露出していないか。
外部 API のクォータ、ドメイン、権限、有効期限を制限しているか。
異常発見後に Key を無効化し、デプロイを素早くロールバックできるか。

AI が書いたコードにもセキュリティレビューは必要です。「自分では一行も書いていない」ほど、安全だと思い込むべきではありません。

今すぐ確認すること

まず自分の GitHub アカウントから確認できます。ユーザー名と次のキーワードを組み合わせて検索します。

API_KEY
SECRET
TOKEN
OPENAI_API_KEY
ANTHROPIC_API_KEY
DEEPSEEK_API_KEY
.env
config
credentials

本物の Key を見つけたら、迷わず先にローテーションし、その後でクリーンアップします。一度でも公開リポジトリに入ったなら、漏洩済みとして扱うべきです。

今後の AI プロジェクトでは、次の流れを固定化すると安全です。

業務コードを書く前に .gitignore を用意する。
.env.example で必要な変数を説明する。
すべての Key は環境変数に置き、ソースコードへ書かない。
API Key には最小権限、クォータ、有効期限を設定する。
GitHub Secret Scanning と Push Protection を有効にする。
公開前に AI にセキュリティチェックを手伝わせても、AI の結論だけを信じない。

AI コーディングの本当の危険は、コードを書き間違えることだけではありません。多くの人が初めて、安全でないアプリを公開インターネットへ素早く出せるようになったことです。速く書くこと自体は問題ではありません。シークレット、データ、権限まで一緒に渡してしまうことが問題です。

参考資料

GPT-5.5、GPT-5.4、GPT-5.3-Codex はどう使い分けるべきか

Sun, 10 May 2026 08:43:17 +0800

結論だけ先に言うと、基本は GPT-5.5、コストや使用量をより重視するなら GPT-5.4、そして Codex 環境で長時間のソフトウェアエンジニアリング作業を回したり、Cloud Tasks や Code Review が必要だったりする場合に GPT-5.3-Codex を重点的に見る、という選び方になります。

これは単なる主観ではありません。2026-05-10 時点でも、OpenAI の Codex 公式ドキュメントでは、多くのタスクは gpt-5.5 から始めることを推奨しています。まだ gpt-5.5 が使えない場合は gpt-5.4 を使い、軽いタスクやサブエージェントには gpt-5.4-mini が向いている、という整理です。

3 つのモデルの位置づけ

まずは公式の位置づけから見ます。

GPT-5.5 は Codex における最新のフロンティアモデルで、複雑なコーディング、コンピュータ操作、ナレッジワーク、リサーチワークフロー向けです。難しい分析、多段階タスク、複数ファイルにまたがる修正、方針設計、重めのドキュメント作業に向く、いわば標準の主力モデルです。

GPT-5.4 はより安定した万能型の選択肢です。公式には、GPT-5.3-Codex の高いコーディング能力に、より強い推論、ツール使用、agentic workflow を組み合わせたモデルと説明されています。つまり、単なる「5.5 の弱い版」ではなく、長期的な主力として使いやすいバランス型です。

GPT-5.3-Codex も依然として非常に強いコーディングモデルですが、強みは実際のソフトウェアエンジニアリングや Codex ネイティブのワークフローにより集中しています。公式ドキュメントでも agentic coding tasks 向けに最適化されたモデルだとされており、GPT-5.4 のコーディング能力自体もその長所を引き継いでいます。

そのため、今の時点では GPT-5.3-Codex をそのまま「最強のコーディングモデル」と考えるのはあまり適切ではありません。日常的な開発では、まず GPT-5.5 と GPT-5.4 を優先して検討するほうが自然です。

用途別にどう選ぶか

日常の Q&A、難しい説明、資料整理、ファイル分析、長文の情報統合のような仕事なら、GPT-5.5 が最も向いています。コードを書くだけでなく、コード以外の負荷の高い知的作業にも強いからです。

複雑なプログラミング、リファクタリング、デバッグ、アーキテクチャ設計、複数ファイルの修正なら、やはり GPT-5.5 が第一候補です。Codex 公式の推奨も同じで、gpt-5.5 が使えるならまずそこから始める、という扱いです。

一方で、品質をある程度維持しながら消費量やコストを抑えたいなら、GPT-5.4 がより現実的な標準モデルになります。通常の開発、一般的なリライト、標準的な翻訳、スクリプト生成、バグ修正の多くでは、GPT-5.4 で十分に強く、しかもクレジット消費を抑えやすいからです。

Codex CLI、IDE 拡張、アプリで、よりエージェント的なソフトウェアエンジニアリング作業を回す場合、たとえば長時間リポジトリを読ませる、継続的にコードを書き換える、タスクをキューに積む、Cloud Tasks や Code Review を使うといった場面では、GPT-5.3-Codex にまだ意味があります。これは GPT-5.5 より新しいからではなく、Codex の Cloud Tasks と Code Review が今も GPT-5.3-Codex で動いているからです。

クレジット消費はどれくらい違うか

Codex の credits 表を見ると、この 3 つの違いはかなりはっきりしています。

Business / New Enterprise のトークン単位の料金では、次の通りです。

GPT-5.5：入力 125 credits / 1M tokens、キャッシュ入力 12.5 credits、出力 750 credits
GPT-5.4：入力 62.5 credits / 1M tokens、キャッシュ入力 6.25 credits、出力 375 credits
GPT-5.3-Codex：入力 43.75 credits / 1M tokens、キャッシュ入力 4.375 credits、出力 350 credits

表面的な単価だけで見ると、GPT-5.4 は GPT-5.5 のほぼ半額です。同じくらいの入出力長で処理するなら、一般には 50% 近く節約できると考えてよいでしょう。GPT-5.3-Codex は入力がより安いものの、出力コストはすでに GPT-5.4 にかなり近いため、「圧倒的に安い選択肢」というわけではありません。

ただし見落としやすい点もあります。Codex 公式には、GPT-5.5 uses significantly fewer tokens to achieve results comparable to GPT-5.4 とあります。つまり単価は高くても、複雑なタスクではトークン使用量の少なさややり直しの減少によって、差が縮まる可能性があります。

それでも、固定テンプレートの記事リライト、翻訳、SEO 説明文のように入出力の長さが比較的安定している仕事では、この「遠回りの少なさ」の恩恵は、複雑なソフトウェアエンジニアリングほど大きくありません。実運用では、GPT-5.4 のほうがやはり安く、だいたい 45% から 50% ほど節約できると考えてよいケースが多いです。

Codex での利用制限の違い

単価だけでなく、Codex 内での使え方も同じではありません。

2026-05-10 時点では、GPT-5.5 は Codex の推奨モデルですが、ChatGPT サインインで使う Codex でのみ利用でき、API key 認証には対応していません。GPT-5.4 と GPT-5.3-Codex は API から利用できます。

また、GPT-5.5 と GPT-5.4 は現時点で Codex Cloud Tasks と Code Review をサポートしていません。この 2 つは今も GPT-5.3-Codex の領域です。つまり、Codex 内で長時間のエンジニアリング作業を回したい場合は、単純にモデルの強さだけでなく、必要な機能が GPT-5.3-Codex に依存していないかも確認する必要があります。

ローカルメッセージだけを使う場合、Plus プランの 5 時間ウィンドウの目安は次の通りです。

GPT-5.5：15-80
GPT-5.4：20-100
GPT-5.3-Codex：30-150

ここからも現実的な違いが見えます。GPT-5.5 は最も強力ですが、固定枠の中では使える回数が少なくなりやすい。GPT-5.4 はよりバランスが良く、GPT-5.3-Codex はローカルメッセージだけを見ると、むしろ粘り強く見えることがあります。

よくある場面ではどう選ぶか

日常業務には、かなり種類の違う高頻度タスクがあります。抽象的に「どれが一番強いか」を考えるより、場面ごとに分けて見るほうが実用的です。

1. 日常の Q&A、資料整理、長文要約

GPT-5.5：最も向いています。曖昧な依頼を処理し、文脈を補い、散らばった情報を構造化するのが得意です。

GPT-5.4：通常の要約や大量整理に向いています。難度が高くなく、量が多いならより経済的です。

GPT-5.3-Codex：主力にはあまり向きません。こなせますが、もっとも得意な領域ではありません。

2. 技術概念の説明、コード解説、古いプロジェクトの読解

GPT-5.5：複雑なプロジェクト向きです。ファイル間の関係が多い、呼び出し経路が長い、歴史的経緯が重い、といった場合により安定します。

GPT-5.4：通常の読解には十分です。関数やモジュールの理解、設定の説明、既存プロジェクトの立ち上がり支援に向いています。

GPT-5.3-Codex：より実行寄りで、解説中心の用途では第一候補ではありません。

3. スクリプト、小ツール、SQL、Shell、正規表現

GPT-5.5：スクリプトの背後にシステム設計があったり、複数サービスが連動したり、制約が複雑だったりする場合に向いています。

GPT-5.4：標準の主力として最も使いやすいです。多くのスクリプト、小ツール、SQL、コマンドライン作業には十分で、しかもクレジット効率が良いです。

GPT-5.3-Codex：スクリプトが大きなエージェントワークフローの一部なら候補になりますが、単体の小さなスクリプト作成で優先する必要はありません。

4. バグ修正、小機能追加、テスト補完、通常開発

GPT-5.5：原因分析、複数ファイル修正、テスト補完まで含む少し重い修正に向いています。

GPT-5.4：日常開発の主力として最適です。一般的なバグ、小機能、テストのひな形、リネーム、整形などでは最もバランスが良いです。

GPT-5.3-Codex：対応できますが、Cloud Tasks やエンジニアリングエージェントが不要なら、普通は第一候補ではありません。

5. 複雑なリファクタリング、設計検討、難しいデバッグ

GPT-5.5：最も向いています。複雑な作業で本当に高くつくのは単発の出力ではなく、やり直しだからです。GPT-5.5 は主問題解決モデルとして使いやすいです。

GPT-5.4：中程度の難しさには向いています。設計案やリファクタリングにも使えますが、非常に長い文脈、多段階推論、不確実性の高い問題では GPT-5.5 ほど安定しないことが多いです。

GPT-5.3-Codex：より実行寄りで、この種の高難度な判断中心タスクでは優先順位は低めです。

6. 大量の軽作業、反復作業、サブタスク分割

GPT-5.5：できますが、通常は割高です。

GPT-5.4：最も向いています。コメントの一括修正、整形の一括処理、定型コード生成、内容のまとめて修正といった場面で最もバランスが良いです。

GPT-5.3-Codex：すでに Codex のエンジニアリングフローの中に組み込まれているなら候補ですが、単純な費用対効果では GPT-5.4 に劣りやすいです。

7. 自動化パイプライン、エージェント実行、継続的なリポジトリ操作

GPT-5.5：初期の設計、ルール作成、複雑なタスク分解に向いています。

GPT-5.4：自動化スクリプトや中程度のワークフローロジックの実装に向いており、特に API から使いたい場合に便利です。

GPT-5.3-Codex：ここでは特に重要です。Codex の Cloud Tasks と Code Review が今もこのモデルで動いているため、「仕組みを自走させる」場面に向いています。

8. 重要ページの文章、ブランド紹介、最終仕上げ

GPT-5.5：最も向いています。自然さ、文体制御、長文の一貫性が最も高いです。

GPT-5.4：通常ページや日常更新には十分です。重要ページは GPT-5.4 で下書きを作り、最後に GPT-5.5 で磨くのが実用的です。

GPT-5.3-Codex：主文案モデルには向きません。

9. 固定テンプレートの記事リライト、翻訳、SEO 説明文

GPT-5.5：テンプレート設計、最終調整、重要ページの仕上げ、より自然な中国語から英語への翻訳に向いています。

GPT-5.4：大量処理の主力に最も向いています。標準的な記事リライト、固定構成の翻訳、商品文案の書き換え、Meta description の一括生成では、品質とコストのバランスが良いです。

GPT-5.3-Codex：主文案モデルには向きません。バッチ処理スクリプト、HTML の整形、タグ構造の保持、自動公開フローの改善などに向いています。

10. EC 商品文案、カテゴリページ、大量コンテンツ運用

GPT-5.5：ルール設計、抜き取り確認、高価値ページの最終仕上げに向いています。

GPT-5.4：大量処理の主力として最適です。商品タイトル、カテゴリ説明、キャンペーン文案、ロングテール SEO コンテンツなどでは、品質とコストのバランスが良いです。

GPT-5.3-Codex：クロール、クリーニング、バッチ処理、自動公開スクリプトには向いていますが、主文案にはあまり向きません。

これらを一言でまとめるなら、次のようになります。

複雑な知的作業、複雑な分析、重要な文章作成：GPT-5.5
日常開発、大量処理、反復作業：GPT-5.4
Codex エンジニアリングエージェント、Cloud Tasks、Code Review：GPT-5.3-Codex

最後にどう使い分けるか

普段の仕事が通常のコーディング、バグ修正、技術相談、付随するドキュメント作成であれば、GPT-5.4 は非常に安定した主力になります。

より複雑なプロジェクト分析、複数ファイルの修正、設計検討、難しいデバッグ、あるいはエンジニアリングと重い知的作業の両方を 1 つのモデルでこなしたいなら、素直に GPT-5.5 を優先するのがよいです。

一方で、Codex 環境そのもののワークフロー、たとえば Cloud Tasks、Code Review、長時間のエージェント実行が重要なら、GPT-5.3-Codex はまだ残す価値があります。ただし、もはや最初の既定選択にするモデルではありません。

固定テンプレートのコンテンツサイトであれば、実用的な組み合わせは次のようになります。

GPT-5.4 で大量生成
GPT-5.5 でテンプレート設計、抜き取り確認、最終仕上げ
GPT-5.3-Codex で自動化ツールを書く

まとめ

現在のより現実的な優先順は、GPT-5.5、GPT-5.4、GPT-5.3-Codex の順です。GPT-5.3-Codex は、よりエンジニアリングエージェント寄り、あるいは Codex 固有機能寄りの場面に置くのが自然です。

もし「同じテンプレート記事をリライトする場合、GPT-5.4 は GPT-5.5 よりどれくらい節約できるのか」を知りたいなら、公式の credits 表とこの種のタスクに典型的なトークン構造を見る限り、「ほぼ半分近く節約できる」と考えてよいでしょう。大量コンテンツサイトではその差は十分に大きいため、GPT-5.5 を最初に使ってルールと文体を固め、その後の大量処理を GPT-5.4 に任せる、という運用がもっとも現実的です。

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 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

DeepSeek V4 FlashでGodotゲームDemo：数セントでどこまで動くのか

Wed, 06 May 2026 09:22:18 +0800

DeepSeek V4 Flash をGodotゲームDemoの開発に使うと、どこまでできるのか。

焦点ははっきりしている。実行でき、観察でき、物理効果を備えた小さなGodot Demoを作れるのかという点だ。

結論から言えば、動く。商用レベルの品質ではないが、ゲームプレイのプロトタイプや物理インタラクションDemoとしては十分に使える。さらに重要なのは、コストが非常に低く、アイデアの素早い検証に向いていることだ。

Demoの表現

このDemoの中心は物理インタラクションだ。

直感的に確認できる効果は次の通り。

ロープを切断できる。
箱が地面に落ちる。
質量を大きくすると、箱の衝突がより激しくなる。
ロープには比較的はっきりした弾性がある。
摩擦と弾性を調整すると、箱に明確な滑りや反発が出る。

見た目の挙動からすると、これは単に「Godotスクリプトを数本生成した」だけではない。実行でき、物理挙動を観察できる小型プロトタイプになっている。

使える度合い

このDemoの価値は「動く、見られる、直せる」ことにある。完全なゲームでも、そのまま商用化できるプロジェクトでもないが、いくつかの点は示している。

DeepSeek V4 Flash はGodot Demoの基本目標を理解できる。
AI Agentは要求を実行可能なプロジェクトに変換できる。
Godotの物理インタラクションのような非Web系タスクも、低コストなプロトタイプ段階に入っている。
個人開発者にとって、アイデアを素早く「見えるもの」に変えられる。

正式なゲームを作るにはもちろん不十分だ。しかし「この遊びは面白いのか」「物理効果はだいたい作れるのか」を検証する目的なら、このDemoはすでに使える。

コスト面の意味

注目すべきなのは、画面がどれだけ精緻かではなく、コストだ。

Godotの物理Demoが数セント程度のモデルコストで実行可能な形になるなら、その意味はプロのゲーム開発を置き換えることではない。プロトタイプの試行錯誤コストを大きく下げることにある。

以前なら、小さなゲームアイデアを検証するだけでも、Godotを理解し、スクリプトを書き、シーンを組み、物理パラメータを調整する必要があった。いまはAI Agentに実行可能な版をまず作らせ、人間が方向性を判断できる。

インディー開発者にとって、この種の低コストな試行は役に立つ。

ゲームプレイのコンセプトを素早く検証する。
他人に見せる一時的なDemoを生成する。
Godot APIや物理システムを探索する。
アイデアを実行可能な初版プロジェクトに変える。
方向性が固まる前の手書きコードコストを減らす。

DeepSeek V4 Flashの表現

注目したいのは、使っているのが DeepSeek V4 Flash であり、より高価で重いフラッグシップモデルではない点だ。

低コストなプロトタイプという位置づけでは、十分よく機能している。最強でも、最も安定しているわけでも、プロダクション工程の納品に最適なモデルでもないが、予算に敏感で、方向性を素早く試したい場面では魅力がある。

向いている場面

DeepSeek V4 Flash + Agent + Godot がより向いているのは、次のようなタスクだ。

小規模なゲームプレイプロトタイプ。
物理効果Demo。
UIまたはインタラクションのコンセプト検証。
教材用サンプル。
Godotプロジェクト構造の理解補助。
実行可能な初版プロジェクトの生成。

一方で、次のようなタスクを直接任せるのには向いていない。

大規模なゲームアーキテクチャ。
複雑なキャラクターコントローラー。
ネットワーク同期。
商用プロジェクトの中核コード。
高精度な物理シミュレーション。
人間のテストを経ない自動コミット。

言い換えれば、第一稿や実験場には向いているが、プロダクション工程の責任者には向いていない。

何を示しているのか

これは、AIコーディングがWeb、スクリプト、バックエンドAPIから、ゲーム開発やインタラクティブプロトタイピングへ広がり続けていることを示している。

かつてゲーム開発の参入障壁は高かった。特にエンジン、スクリプト、アセット管理、物理システムが絡み合うと、初心者は詰まりやすい。いまはモデルとAgentツールで先にプロジェクトを組み立て、開発者はゲーム性の判断や効果の調整に集中しやすくなっている。

この変化は、主に三つの影響をもたらす可能性がある。

第一に、ゲームプロトタイプが安くなる。多くのアイデアは完全開発まで待たずに、まず実行可能なDemoとして検証できる。

第二に、インディー開発者がより試しやすくなる。Godotを知らない人でも、AIの助けでプロジェクト構造と基本フローに触れられる。

第三に、モデルの安定性がより重要になる。ゲーム開発はコードが動くだけでは足りない。効果が自然で、操作感がまともで、パラメータを制御できる必要がある。今後、実際の画面や実行状態とよりうまく結びつけられるモデルほど、この種のタスクに向く。

まとめ

DeepSeek V4 FlashでGodot Demoを作ることは、一言で言えばこうだ。完璧ではないが、十分安く、十分速く、プロトタイプには十分向いている。

商用ゲームにはまだ遠いが、非常に低いコストで小さなゲームアイデアを検証する目的なら、すでに価値がある。

個人開発者にとって現実的な使い方は、ゲーム全体をAIに任せることではない。まずAIに動く工程を出させ、その後の判断、取捨選択、磨き込みを人間が担当することだ。この使い方なら、DeepSeek V4 Flashのような低コストモデルはかなり魅力的になる。

Codex App 入門ガイド：インストール、サンドボックス、並列タスク、Skills、MCP

Wed, 06 May 2026 08:41:17 +0800

Codex App は、AI コーディング向けのタスクワークスペースと考えると分かりやすい。従来の IDE でも、単なるチャット画面でもなく、マルチタスク、プロジェクト管理、サンドボックス権限、Git、クラウド実行、プラグイン、Skills、MCP、自動化を 1 つのインターフェイスにまとめている。

すでに Codex CLI、Claude Code、Cursor、その他の coding agent を使っているなら、Codex App の最も注目すべき点は、「複数の agent を並列に動かす」ことをより明確なデスクトップワークフローにしている点だ。

Codex App が向いていること

Codex App の価値は、AI に質問へ答えさせることではなく、プロジェクトディレクトリ内で継続的にタスクを実行させることにある。

コードを編集し、コマンドを実行し、開発サーバーを起動する。
複数のプロジェクトと複数のタスクを管理する。
ローカルまたはクラウドで長いタスクを実行する。
プラグイン、Skills、MCP を呼び出して能力を拡張する。
Git、worktree、PR で変更を管理する。

OpenAI も Codex App を複数の coding agent を管理するためのインターフェイスとして位置付けている。複数のコードタスクを同時に進める人に向いており、特にフロントエンドページ、スクリプト、小規模アプリ、ドキュメント整理、自動化ワークフローと相性がよい。

インストール前の準備

Codex App を使う前に、次の 3 つの基本ツールを用意しておくとよい。

Git
Node.js
VS Code または普段使っている IDE

Codex App は macOS と Windows をサポートしている。インストール後は ChatGPT アカウントでログインする。初回起動時には、プログラミングや日常作業など主な利用シナリオを選択できる。Codex は選択内容に応じて一部のプラグインと Skills を事前に入れ、後から設定やプラグインマーケットで調整できる。

Windows と macOS の主な機能はおおむね同じだが、一部のコンピューター自動化機能はプラットフォームやプラグイン対応に依存する。実際には現在のバージョンに表示される内容を基準にする。

インターフェイス構造：プロジェクト、タスク、チャット

Codex App は典型的な 3 カラム構成になっている。

左側：プロジェクト、タスク、過去のチャット、プラグイン、自動化への入口。
中央：現在のチャット画面。
右側：ファイル、ブラウザー、ターミナル、実行結果などの多機能領域。

1 つのプロジェクトは通常、ローカルフォルダーに対応する。同じプロジェクト内で複数のチャットを開くことも、複数のプロジェクトを同時に開き、異なる agent に並列で作業させることもできる。

タスクリストには状態が表示される。

実行中：agent がまだ作業している。
承認待ち：権限、ネットワーク、依存関係インストール、高リスク操作の確認が必要。
完了：タスクが終了し、結果確認や追加質問ができる。

複数のターミナルを行き来するより直感的で、複数の AI タスクを同時に管理しやすい。

サンドボックスと権限管理

Codex App の権限体系はサンドボックスを中心にしている。デフォルトでは、現在のプロジェクトフォルダーが agent の主な作業範囲になる。

一般的な権限境界は次の通り。

プロジェクトディレクトリ内のファイルを読み書きできる。
デフォルトではプロジェクト外のファイルを自由に変更できない。
ネットワークや高リスクコマンドはデフォルトで制限される。
権限昇格が必要な場合はユーザーに承認を求める。

実用的なのは「自動レビュー」モードだ。低リスク操作は自動で許可し、高リスク操作はユーザー確認に回す。これにより頻繁なポップアップを減らしつつ、危険な操作が知らないうちに実行されることを防げる。

「完全アクセス」は慎重に使うべきだ。agent が何をする必要があるか明確で、プロジェクトが Git でバックアップされ、重要ファイルにも別のバックアップがある場合に向いている。日常的に常時有効にするのはおすすめしない。

コンテキスト、モデル、利用枠

Codex App は現在のチャットのコンテキスト使用状況を表示する。会話が長く、履歴が多いほど、モデルが処理するコンテキストも大きくなる。

実用的な習慣は次の通り。

1 つのタスクが終わったら新しいチャットを開く。
長い会話は手動圧縮できるが、圧縮を万能の記憶と考えない。
複雑なタスクでは、目的、境界、受け入れ条件を先に明確にする。
関係ない大量のログ、エラー、ファイルを一度に詰め込まない。

モデル選択では、タスクの複雑さに応じて推論強度を調整する。簡単な修正、文章整理、反復タスクは必ずしも最高性能モデルを必要としない。アーキテクチャ移行、難しいバグ、複数ファイルにまたがるリファクタリングには、より強いモデルが向いている。

高速モードがある場合は、通常より利用枠を多く消費する点に注意する。急ぎの時には有効だが、日常のデフォルトにする必要はない。

画像生成とマルチモーダル入力

Codex App は画像やファイルをコンテキストとして受け取ることができ、適切な場面では画像生成能力も呼び出せる。

これはフロントエンドやコンテンツ系プロジェクトで役立つ。たとえば Codex に次のことを依頼できる。

スクリーンショットをもとにページスタイルを修正する。
Web ページ内の不適切な画像を置き換える。
商品画像、カルーセル画像、ページ素材を生成する。
UI スクリーンショットから修正すべき位置を指摘する。

より効率的なのは、「もっときれいにして」とだけ言うのではなく、スクリーンショットを使って具体的な問題を示すことだ。たとえば「このカードの余白が大きすぎる」「この画像はサービスシーンに合っていない」「地図エリアをもっと分かりやすくする」といった指示がよい。

Steer：実行中に方向を修正する

Steer は、実行中に方向を引き受ける機能と考えるとよい。agent がすでに作業を始めた後で、方向を誤解していると気づいた場合、すべて終わるまで待ってから直す必要はない。

この機能を使うと、新しい指示を現在の実行フローに挿入し、Codex に進路を修正させられる。

Steer が向いている場面は次の通り。

agent が要件を誤解した。
生成されたページのスタイルが明らかに違う。
実行中の案が重すぎる、またはコストが高すぎる。
途中で重要な制約を追加する必要がある。

通常はデフォルトのキュー動作を維持し、本当に介入が必要な時だけ手動で Steer を使うのがよい。通常のタスクを乱さず、重要な場面で方向を戻せる。

計画モードと内蔵ブラウザー

複雑なタスクでは、まず計画モードを使うのがよい。計画モードでは Codex はすぐにコードを変更せず、先に計画を出し、必要ならカード形式で重要な選択肢を確認する。

計画モードに向いているタスクは次の通り。

React プロジェクトを Next.js に移すようなフレームワーク移行。
大規模リファクタリング。
データベース、認証、デプロイを含む機能。
技術方針がまだ固まっていない要件。

Codex App の右側領域では内蔵ブラウザーを開き、ローカル開発サーバーをプレビューできる。ページ上で注釈を付け、具体的な UI 位置に応じて Codex に修正させられる。この「ページを見る、位置を指す、AI に直させる」流れは、純粋な文章説明よりフロントエンドデバッグに向いている。

Git、IDE、コードのロールバック

Codex App は完全な IDE ではない。コード閲覧や注釈はできるが、手作業での編集は VS Code、Cursor、Windsurf などの IDE の方が向いている。

Codex プロジェクトでは早めに Git を初期化しておくとよい。

Codex に .gitignore を作成または確認させる。
使える状態になったら一度コミットする。
大きな変更の前にはクリーンなコミット地点を作る。
不満があれば Git でコードを戻す。

チャット履歴だけを戻しても、コードは自動では戻らない。安定した方法は、チャットを適切な地点へ戻し、コードは Git commit hash で対応する状態へ戻すことだ。

Worktree：複数方向の並列開発

git worktree は Codex App で並列 agent を使う際に非常に相性がよい。

本質的には、同じリポジトリから複数の独立した作業ディレクトリを作り、それぞれを別ブランチに対応させる仕組みだ。これにより、異なる agent を別フォルダーで同時に作業させても互いに上書きしない。

典型的な使い方は次の通り。

1 つの worktree で顧客レビューコンポーネントを改善する。
1 つの worktree で店舗情報と地図レイアウトを調整する。
2 つのタスクが終わったらそれぞれ main へマージする。
マージ後に一時 worktree を削除する。

同じディレクトリで複数 agent に同時編集させるよりずっと安定する。競合が出た場合も、通常の Git フローで review と merge を行えばよい。

クラウド実行環境

Codex はローカルだけでなく、クラウド環境にもタスクを委任できる。

クラウド実行が向いている場面は次の通り。

外出中で手元にスマートフォンしかない。
agent に長いタスクをバックグラウンドで実行させたい。
コードがすでに GitHub に同期されており、Codex にリモートリポジトリを変更させたい。
PR 形式で変更を確認してマージしたい。

典型的な流れは、ローカルコードを GitHub に push し、Codex がクラウド環境でリポジトリを取得してタスクを実行し、変更を生成し、PR または diff としてレビューに出すというものだ。

ローカルで開発を続ける場合は、リモートの最新変更を取り込むことを忘れない。

記憶システム：AGENTS.md を整える

新しいチャットはデフォルトでは完全な履歴記憶を持たない。プロジェクトが複雑になると、毎回背景を説明し直すのは非効率だ。

最も汎用的な方法は、プロジェクトルートに AGENTS.md を置くことだ。このファイルには次の内容を記録できる。

プロジェクトの目的と主要技術スタック。
よく使うコマンド。
ディレクトリ構成。
コードスタイルと命名規則。
禁止事項、たとえばファイルの一括削除を避けること。
テスト、ビルド、デプロイルール。

Codex にプロジェクトを読ませて AGENTS.md の初版を生成させ、人間が確認する方法もよい。複雑なプロジェクトでは、このファイルを維持する価値が高い。

グローバルルールは慎重に使う。全プロジェクトに共通する安全制約、たとえば「ディレクトリを再帰的に削除しない」「破壊的操作の前に確認する」などに向いている。特定プロジェクトの細部をグローバルルールに入れると、他のプロジェクトを汚染する。

プラグインと自動化

プラグインは、GitHub、Gmail、Google Drive、データベース、デプロイ基盤など外部サービスを Codex に接続する。

価値はコピー&ペーストを減らすことだ。たとえば Codex に次のことをさせられる。

GitHub リポジトリの star 推移を確認する。
メール内容を整理して自分に送る。
定期的なチェックを実行する。
結果を要約として書く。

自動化は繰り返しタスクに向いている。たとえば毎週金曜午後にリポジトリデータを確認し、メールレポートを送るような用途だ。簡単な自動化タスクには最高性能モデルは不要で、軽量モデルで十分なことが多い。

Skills：ワークフローを再利用可能な能力にする

Skills は Codex の「専門的な手順書」だ。一回限りのプロンプトではなく、ある種類のタスクの流れ、規則、スクリプト、注意点をまとめ、Codex が後で安定して再利用できるようにする。

主な入手元は次の 3 種類。

公式 Skills。
サードパーティ Skills。
自分で書いた Skills。

Skill 化に向いている作業は次の通り。

字幕を図解付きノートにする。
会社の形式で週報を書く。
画像や文書を一括処理する。
固定形式のコードレビュー。
特定フレームワークのプロジェクト初期化。

同じプロンプトを何度もコピーしているなら、Skill にする価値がある。

MCP：外部ツールとデータベースを接続する

MCP は、大規模モデル向けの標準化されたツールプロトコルと考えられる。MCP を通じて、Codex は外部サービスを呼び出し、より具体的なタスクを完了できる。

たとえば Supabase を接続すると、Codex に次のことをさせられる。

データベーステーブルを作成する。
データベーススキーマを読む。
バックエンドエンドポイントを変更する。
フロントエンドフォームをデータベースへ送信する。
データベース状態に基づいて問題をデバッグする。

これは強力だが、権限境界に注意が必要だ。データベース、本番環境、デプロイ基盤、メールアカウントは高リスク資源である。初回接続時はテストプロジェクトと低権限アカウントを使うのがよい。

デプロイプラグイン

デプロイ基盤のプラグインを使うと、Codex がビルドと公開を直接完了できる。たとえばフロントエンドプロジェクトを Netlify のような平台へデプロイできる。

この種のプラグインは、小規模サイト、プロトタイプ、社内ツール、デモプロジェクトに向いている。実際に使う時は次の点に注意する。

デプロイ前にローカルビルドを実行する。
環境変数をコードへ直接書かない。
公開後にページが正常に開くか確認する。
本番プロジェクトでは人間の review を残す。

AI は公開フローをつなぐ助けになるが、デプロイ権限は慎重に管理すべきだ。

コンピューター自動化

対応プラットフォームとプラグイン環境では、Codex がブラウザーやデスクトップアプリを操作し、RPA に近いタスクを実行できる。

例：

チャットアプリを開いてメッセージを準備する。
プロジェクトボードを閲覧し、タスク状態を要約する。
英語のブリーフを生成する。
確認後、指定相手へ送信する。
この流れをスケジュール自動化にする。

この機能は想像力を広げるが、最も強い安全境界も必要だ。メッセージ送信、メール送信、フォーム送信、支払い、データ削除に関わる操作では、人間の確認を残すべきだ。

使い方の提案

Codex App の正しい使い方は、すべてを一度に完全自動化させることではない。タスクを明確に分解し、制御された環境で効率よく実行させることだ。

おすすめの習慣：

すべてのプロジェクトで最初に Git を初期化する。
複雑なタスクでは計画モードを使う。
並列タスクでは worktree を優先する。
プロジェクトルールを AGENTS.md に書く。
高リスク操作では人間の確認を残す。
繰り返しワークフローを Skill や自動化にする。
プラグインと MCP はまずテスト環境で検証する。

参考資料

まとめ

Codex App の本質は「もう 1 つの AI チャット画面」ではない。AI コーディングを管理可能なワークスペースにすることだ。ローカルプロジェクト、クラウドタスク、Git、worktree、プラグイン、Skills、MCP、自動化をつなげられる。

うまく使う鍵は、「任せること」と「制御すること」のバランスを取ることだ。小さなタスクは大胆に Codex に渡し、複雑なタスクはまず計画させ、高リスク操作は必ず確認する。そうすれば Codex は、コードを書く助手から、長期的に協力できるエンジニアリングツールへ近づく。

テストと振る舞いの記述で AI コーディングを制御し、負債を増やさない

Tue, 05 May 2026 14:35:38 +0800

AI にコードを書かせると、よくある体験があります。最初は速いのに、後半になるほど乱れていく、というものです。機能の立ち上げはすぐにできますが、プロジェクトが大きくなり、修正回数が増えると、ひとつの bug を直したあとに三つの bug が出てくるような状態になりがちです。

これは完全に AI だけの問題ではありません。人間の開発者も同じような書き方をすることがあります。ただ、AI は書く速度が速いので、問題が表面化する速度も速くなります。この制御不能感を減らすには、AI に「もっと頑張らせる」のではなく、より明確な境界を与えることが重要です。まず何を正しい結果とするのかを定義し、そのうえで実装させます。

TDD と BDD は、AI コーディングの流れに組み込みやすい考え方です。TDD は「正しいかどうか」を自動テストに変えます。BDD は「これは本当に欲しい機能か」を人間が読める振る舞いの記述に変えます。両方を組み合わせると、AI の推測や自由解釈を減らし、結果を確認しやすくできます。

TDD が解決する問題

TDD は Test Driven Development、つまりテスト駆動開発です。基本的な順序は次の通りです。

先にテストを書く。
テストを実行し、現時点では失敗することを確認する。
機能コードを書く。
テストが通るまで実装を修正し続ける。

これは多くの人が慣れているやり方とは逆です。たとえばソート関数を書く場合、直感的には先に関数を書き、いくつか数字を入力して結果が合っているかを確認したくなります。TDD では、先に期待結果をテストとして書きます。たとえば [3, 1, 2] を入力したら [1, 2, 3] が返る、空配列を入力したら空配列が返る、重複した数字を含む配列でも正しく並ぶ、という具合です。

この意味は、開発を始める前に正しい結果が明確に定義されることです。その後、誰がコードを変更しても、テストを再実行すれば、以前合意した振る舞いを壊していないか確認できます。

なぜ以前は TDD を続けにくかったのか

TDD は聞こえはよいですが、実際のプロジェクトで継続するのは簡単ではありません。

第一に、直感に反します。空のファイルを前にすると、多くの人は先に機能を書きたくなります。特に要件がまだ曖昧なときは、テストケースを書くこと自体が難しくなります。

第二に、要件はすぐ変わります。今日まじめに書いた十数個のテストが、明日の要件変更で大きく書き直しになるかもしれません。短期的には、開発のテンポが遅く見えます。

第三に、テスト自体にもコストがあります。テストコードは自然に生えてくるものではありません。以前は、開発者が自分で書き、保守し、その価値を説明する必要がありました。短期の納期だけを見るチームでは、この作業は削られやすいものです。

しかし AI はこのコスト構造を変えました。要件をテストコードに変換する作業は、AI が得意な領域です。曖昧な説明を自由に解釈させるより、テストに沿って実装させるほうがずっと安定します。

AI にコードを書かせるときの TDD の使い方

AI に機能を書かせるときは、「この機能を実装して」ではなく、次の順序で依頼します。

まず AI に要件からテストケースを列挙させる。
各テストケースに自然言語の説明を付けさせる。
テストケースが実際の要件に合っているか review する。
テストを確認したあとで、AI に機能を実装させる。
AI にテストを実行させ、失敗結果に基づいて修正を続けさせる。

このとき、人間が主に review するのは大きな実装コードではなく、テストが要件を明確に表しているかどうかです。テストケースはたいてい「入力は何か、出力はどうあるべきか、境界条件をどう扱うか」に近いので、実装ロジックを直接読むよりかなり楽です。

たとえば AI には次のように依頼できます。

1
2
3

まだ機能を実装しないでください。
以下の要件に基づいてテストケースを書いてください。各テストケースには、カバーする業務ルールを自然言語のコメントで説明してください。
テストを確認したあとで、そのテストに基づいてコードを実装してください。

この流れは、AI が書いている途中で要件から外れる問題と、後続の修正で既存機能を壊す問題を減らせます。

TDD だけでは足りない

TDD だけでは、まだ二つの穴があります。

一つ目は、テストがすべて通っても、プロダクトが本当に期待通りとは限らないことです。テストは、コードがテストに書かれたルールを満たしていることしか証明しません。テストそのものがユーザーの要求を正しく表現していなければ、コードは「正しく間違ったこと」をしてしまいます。

二つ目は、テストコードが非エンジニアにとってまだ読みやすいものではないことです。自然言語のコメントがあっても、多くの人は大量のユニットテストを読みたがりません。要件がプロダクト体験寄りになるほど、テストコードだけで「これは自分が欲しかったものか」を確認するのは難しくなります。

そこで BDD が必要になります。

BDD が解決する問題

BDD は Behavior Driven Development、つまり振る舞い駆動開発です。コード内部をどう書くかではなく、ある場面でシステムがどのように振る舞うべきかに注目します。

BDD ではよく Given / When / Then という形式を使います。

Given：ある前提状態。
When：ユーザーまたはシステムが行う操作。
Then：期待される結果。

たとえば吸血効果を持つゲームキャラクターは、次のように記述できます。

Given 盤面に、残り HP が 1、攻撃力が 2、最大 HP が 5 の吸血鬼がいる
And 隣接マスに、残り HP が 10 の敵ユニットがいる
When 吸血鬼がその敵ユニットを攻撃する
Then 敵ユニットの残り HP は 8 になる
And 吸血鬼の HP は 3 まで回復する

これはコードではありませんが、「敵を攻撃したときに生命値を回復する」よりずっと正確です。初期状態、操作、結果が書かれていますし、あとで補うべき問題も見えてきます。敵の HP が 1 しかない場合、吸血鬼は実際に与えたダメージ分だけ回復するのか、それとも攻撃力分回復するのか。吸血鬼がすでに最大 HP の場合、超過分の回復はどう扱うのか。

こうした問いが早く出てくるほど、あとで AI が勝手に推測する余地は減ります。

なぜ BDD は AI と相性がよいのか

BDD も以前は導入コストが低くありませんでした。プロダクト、開発、テストが同じ振る舞いの記述でコミュニケーションする必要があるからです。しかし現実には、そのような協作習慣を持たないチームも多いです。

AI 時代には、BDD のコストが下がります。まず次のような粗い要件を一文で書くだけで十分です。

`1`	`吸血鬼が敵を攻撃したあと、与えたダメージと同じ量の HP を回復する。`

そのうえで、AI に Given / When / Then のシナリオを生成させます。うまく動く AI なら、境界条件を追加し、不明確なルールを質問してきます。人間がやるべきことは、実装コードを直接読むことではなく、その振る舞いの記述を確認することです。

振る舞いの記述が明確になったら、AI にそれをテストコードへ変換させ、最後にテストに基づいて機能を実装させます。この流れはかなりスムーズです。

より安定した AI コーディングフロー

実際には、BDD と TDD をつなげて使えます。

まず自然言語で要件を書く。
AI に BDD の振る舞いシナリオへ変換させる。
人間が Given / When / Then が期待通りか確認する。
AI に振る舞いシナリオを自動テストへ変換させる。
人間がテストのカバー範囲を素早く review する。
AI に機能を実装させる。
テストを実行し、失敗したら AI にエラーに基づいて修正させる。
最後に人間が受け入れ確認とコード review を行う。

ここで重要なのは順序です。最初から AI に完全な実装を書かせるのではなく、まず要件を確認可能な振る舞いに変え、次に実行可能なテストに変えます。こうすると、AI が自由に解釈できる余地はかなり小さくなります。

次のようなプロンプトをそのまま使えます。

この要件を BDD + TDD の流れで処理してください。

ステップ1：まず要件を Given / When / Then の振る舞いシナリオに整理してください。コードは書かないでください。
ステップ2：不明確なルールを列挙し、私に確認してください。
ステップ3：振る舞いシナリオが確認されたあとで、それらをテストケースに変換してください。
ステップ4：テストが確認されたあとで、機能を実装してください。
ステップ5：テストを実行し、失敗結果に基づいて修正し、すべてのテストが通るまで続けてください。

この種のプロンプトは複雑ではありませんが、AI の働き方をはっきり変えます。いきなり完成しているように見えるが検証しにくいコードを書くのではなく、先に要件を絞り込み、その後で実装に入るようになります。

優先して使いたい場面

BDD + TDD はすべてのタスクに必要なわけではありません。一回限りのスクリプト、一時的なデータ処理、小さなスタイル調整では、完全な流れは重すぎるかもしれません。

より向いているのは次のような場面です。

業務ルールが多く、誤解しやすい。
境界条件が多く、今後も継続的に変更される。
ゲーム、課金、権限、状態機械、フォームバリデーションなど、ロジックが濃い機能。
複数人で要件を確認する必要がある。
コードを長期保守する予定で、一度生成して終わりではない。
すでに「AI が修正するほど乱れていく」状態が出ているプロジェクト。

AI にボタン文言をひとつ変えさせるだけなら、完全な流れは不要です。しかしキャラクタースキルシステム、注文状態の遷移、権限判定、ポイントルールなどを作るなら、先に振る舞いシナリオとテストを書くほうが割に合います。

使うときの注意点

第一に、テストは多ければよいわけではありません。テストは重要なルールと高リスクな境界をカバーすべきで、実装の細部をすべて固定するものではありません。そうしないと、少しの要件変更でもテストが保守負担になります。

第二に、BDD シナリオは具体的に書く必要があります。「システムは正常に動作するべき」「体験は滑らかであるべき」のような検証できない記述は避けます。どの状態で、何が起き、結果がどうなるべきかを明確に書きます。

第三に、人間の review はまだ必要です。AI はテストや振る舞いシナリオを生成できますが、あなたが本当に望むプロダクト上の取捨選択までは知りません。特に境界ルールは、人間が確認する必要があります。

第四に、テストが通ったあとも、実際に機能を動かす必要があります。自動テストはロジックの問題を受け止められますが、UI 体験、性能、インタラクションの細部、ユーザー感覚は人間の受け入れ確認が必要です。

まとめ

AI はコードを書くのが速いですが、速さは安定性と同じではありません。要件が複雑になるほど、「これを実装して」という一文だけに頼るべきではありません。よりよい方法は、要件を確認可能な振る舞いに分解し、その振る舞いを実行可能なテストに変え、最後に AI にテストに沿ってコードを実装させることです。

TDD は AI に何を正しい結果とするかを伝えます。BDD は人間が、その機能が本当に欲しかったものかを確認しやすくします。両者を組み合わせる目的は儀式を増やすことではありません。AI の推測空間を減らし、「速く書く」を「安定して変更する」に変えることです。

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 ツールに標準で見せないこと、予算と使用量に上限を設けること。ツール提供側には、自動ファイル読み込みに対して見えるコスト表示と保護機構が必要です。

参考：

Claude.md は長ければよいわけではない：AI コーディング用のグローバルメモリファイルの書き方

Wed, 29 Apr 2026 21:07:37 +0800

最近、AI コーディング用のグローバルメモリファイルについての議論を見かけました。プロジェクトに Claude.md や AGENTS.md のようなファイルを追加しても、必ずしも結果がよくなるとは限らず、場合によっては成功率が下がり、推論コストも上がるという話です。

一見すると直感に反します。AI にプロジェクト背景、ルール、説明を多く渡せば、より正確にコードを書けるはずだと思いがちです。
しかし本当の問題は、Claude.md が普通のドキュメントではないことにあります。これは毎回の会話でコンテキストに挿入されるグローバルメモリです。内容が多ければ、モデルは毎回それだけ多く読む必要があります。内容が曖昧なら、毎回余計な判断が増えます。本来入れるべきではない手順を書いてしまうと、関係のないタスクでも不要な動作が発火する可能性があります。

つまり、Claude.md を書く難しさは、内容をすべて書き切ることではありません。どの情報が長期的にコンテキストを占有する価値があるかを判断することです。

Claude.md とは何か

AI コーディングツールにおいて、Claude.md や AGENTS.md のようなファイルは、本質的にはグローバルメモリファイルです。

通常の会話もコンテキストに入りますが、コンテキスト長には上限があります。会話が長くなると、履歴は圧縮され、一部の細部は失われます。グローバルメモリファイルの役割は、重要なルールを固定し、モデルが毎回のタスク開始時に参照できるようにすることです。

これは二つの意味を持ちます。

書いた内容は忘れられにくい
書いた内容は毎回のタスクでコストになる

これは必要なときだけ読まれる README とは違います。長期的に有効な作業制約に近いものです。一度入れると、デフォルトで毎回モデルの判断に影響します。

そのため、Claude.md はプロジェクト紹介でも、経験メモでも、すべての開発手順を詰め込む場所でもありません。モデルが知らないと同じミスを繰り返しやすいルールだけを置くべきです。

なぜ逆効果になることがあるのか

グローバルメモリファイルの書き方が悪いと、主に三つの問題が起きます。

一つ目は、コンテキストを消費することです。

Claude.md が一千行ある場合、その一千行は長期的にモデルのコンテキストに入ります。現在のタスクに本当に関係するコード、エラーメッセージ、要求仕様が圧迫されるかもしれません。コンテキストは無料の空間ではありません。グローバルルールが大きいほど、現在のタスクの焦点は薄まりやすくなります。

二つ目は、余計な行動を誘発することです。

たとえば、グローバルファイルに次のように書いたとします。

1
2

毎回タスクを始める前に、プロジェクトディレクトリを完全に読む。
毎回変更後に、完全なエンドツーエンドテストを実行する。

これらは責任ある指示に見えますが、グローバルメモリに置くと「すべてのタスクで実行する」という意味になります。たとえ一行の文言修正であっても、モデルはこのルールに従って不要な探索やテストを行うかもしれません。結果として、作業は遅くなり、コストは上がり、ときには新しい干渉も生まれます。

三つ目は、判断負荷を増やすことです。

「コードをエレガント、簡潔、保守しやすく、拡張しやすく保つ」のような文は正しく聞こえますが、実際の制約としては弱いです。モデルはコードを生成するたびに、何がエレガントで何が拡張しやすいのかを判断しなければなりません。しかし明確な境界は与えられていません。

よりよい書き方は、抽象的な美徳を並べることではなく、具体的な禁止事項や反例を書くことです。たとえば：

1
2
3

単一の呼び出し箇所のために汎用抽象を追加しない。
テストカバレッジなしで共有パース処理を変更しない。
一時スクリプトをアプリケーションのソースディレクトリに置かない。

これらのルールは具体的で、実行しやすいものです。

何を書くべきか

ある内容を Claude.md に書くべきかどうかは、単純な基準で判断できます。

それを書かないと AI が同じ種類のミスを繰り返すなら、書く価値があります。

グローバルメモリファイルに向いている内容には、だいたい次の特徴があります。

長期的に有効である
現在のリポジトリと強く関係している
コード構造から自然には推測できない
モデルの行動を明確に変える
制約、禁止事項、パス規則、固定コマンドであることが望ましい

たとえば：

すべての Hugo 記事では index.zh-cn.md だけを編集し、他言語版を自動生成しない。
記事の front matter には title/date/draft/tags/categories/slug/description が必須。
public/ 配下の生成物を変更しない。
PowerShell でデプロイするときは scripts/deploy.ps1 を使う。

これらは曖昧な助言ではありません。リポジトリの実際の作業方法に結びついています。モデルが知らなければ間違える可能性があり、知っていれば実際に誤操作を減らせます。

書くべきではないもの

多くの人は Claude.md をプロジェクト説明書にしてしまいがちですが、通常それは不要です。

あまり向いていない内容は次のようなものです。

プロジェクトのビジョンや背景紹介
長いディレクトリ構成説明
一時的なタスク計画
一回限りのデバッグ手順
抽象的なコード品質スローガン
一部の状況でしか必要ない長いワークフロー

たとえば「これは商品、注文、ユーザーモジュールを含む EC プロジェクトです」という説明は、具体的なコーディングタスクにはあまり役立ちません。実際の開発では、モデルは現在の要求、仕様書、コード構造、テストに基づいて判断すべきであり、グローバルメモリ内の粗い紹介に頼るべきではありません。

ディレクトリ構成も同じです。「共有コンポーネントはこのディレクトリからのみ参照する」のような特別な約束がある場合を除き、ツリー全体を書く必要はありません。モデルはプロジェクトディレクトリを自分で読めます。静的な構成説明は古くなりやすいだけです。

手順は skills やコマンドに向いている

ある内容が「第一にこれをする、第二にこれをする、第三にこれをする」という手順なら、それは Claude.md に置くべきではないかもしれません。

長期的なワークフローは、skills、スクリプト、コマンドに分離できます。そうすれば、グローバルメモリには名前と発火条件だけを残し、詳細な手順は必要なときだけ読み込めます。

たとえば：

1
2

ユーザーが Hugo 記事の翻訳を依頼したら、post-translate skill を使う。
ユーザーがサイトのデプロイを依頼したら、hugo-rsync-deploy ワークフローを実行する。

完全な翻訳手順やデプロイ手順を Claude.md に書くより軽くなります。グローバルメモリは短く保ち、具体的な流れは起動可能なツールに任せます。

Claude の最近の初期化フローもこの方向に進んでいます。単に Claude.md を生成するだけでなく、再利用可能なワークフローを skills に、固定イベントを hooks に分けようとします。この変化の背景にある考え方は明確です。グローバルメモリは入口だけを担い、詳細は必要に応じて読み込むべきです。

Claude.md は継続的に改善するもの

Claude.md は一度書いて終わりにすべきではありません。

より現実的なのは、最初は短く保ち、実際のタスクの中で問題を露出させることです。あるミスが一度だけ起きたなら、まず人間が処理すれば十分です。同種のミスが二回以上起きたなら、それはグローバルルールとして残す価値があるかもしれません。

最初から大量のルールを書くより、このような反復のほうが効果的です。初期段階では、どのルールが本当に役立つのか、どの内容がノイズになるのか分かりません。プロジェクトが大きくなり、協業が増え、モデルの挙動が安定してきたら、高頻度の問題を少しずつ追加していけばよいのです。

もう一つ重要な傾向があります。モデルが強くなるほど、グローバルメモリファイルは短くあるべきです。

以前はプロンプトに書く必要があった多くの要求を、今のモデルは自然に処理できます。そうした基本要求を Claude.md に入れ続けると、コンテキスト負荷が増えるだけです。グローバルメモリはモデル能力の向上に合わせて縮小し、このリポジトリ固有で、モデルが自動推測できない内容だけを残すべきです。

より実用的な書き方

Claude.md を書くときは、次の順序で考えるとよいです。

このリポジトリにはどんな特別な約束があるか？
モデルがすでに二回以上犯したミスは何か？
誤用してはいけないディレクトリ、ファイル、コマンドは何か？
どの手順は常駐コンテキストではなく、skills、スクリプト、コマンドにすべきか？
どの内容は単なる紹介で、削除できるか？

最終的なファイルは数十行だけかもしれません。プロジェクト全体を説明する必要はありません。行動を正確に制約することが目的です。

よい Claude.md は、たとえば次のようになります。

# 作業ルール

- 現在のタスクに関係するファイルだけを編集する。
- public/ や resources/ のような生成物ディレクトリを変更しない。
- Hugo 記事の書き換えでは index.zh-cn.md だけを処理し、他言語版を生成しない。
- デプロイが関係する場合は、先に Hugo ビルドを実行し、その後既存の rsync スクリプトを実行する。
- 既存のユーザー変更がある場合は、巻き戻さず、現在の状態を前提に続ける。

短いですが、どの行も実際の行動に影響します。こういう内容こそ、長期的にコンテキストを占有する価値があります。

最後に

Claude.md の価値は、AI に「もっと多くを知ってもらう」ことではありません。AI に「決まったミスを減らしてもらう」ことです。

これは知識ベースでもプロジェクト百科でもありません。AI コーディングにおける長期的な制約ファイルです。
具体的で、短く、実際のミスに近いほど役に立ちます。逆に、汎用的で、長く、プロジェクト紹介のようになるほど、モデルを遅くし、結果を悪化させる可能性が高くなります。

グローバルメモリは無限のメモ帳ではなく、希少な資源として扱う。これが、よい Claude.md を書くためのもっとも重要な原則かもしれません。

GPT 5.5、Claude Opus 4.7、DeepSeek V4、Qwen 3.6 Max はどう選ぶべきか

Tue, 28 Apr 2026 22:18:00 +0800

もし今すぐ一言だけ答えが欲しいなら、まずはこの形で覚えておけば十分です。

いちばん安定していて、時間も無駄にしにくいのは GPT 5.5
ページの見た目、創意、プレゼン感を重視するなら Claude Opus 4.7
中国系モデルの中で最前線にかなり近いのは Qwen 3.6 Max
DeepSeek V4 も弱くはないが、出力の波はやや大きい

「今いちばん強いコーディングAIはどれか」と聞く人は多いですが、実際にはランキングを知りたいというより、もっと現実的なことを知りたいはずです。
ページを書きたい、デモを作りたい、小さなツールを作りたい、インタラクションを足したい。そのとき最初の一回で使えるものを出してくれるのはどれか。

その視点で見ると、この数モデルの違いはかなりはっきりしています。

まず全体の判断

GPT 5.5、Claude Opus 4.7、DeepSeek V4、Qwen 3.6 Max を並べて見たとき、総合的にいちばん安定しているのはやはり GPT 5.5 です。

毎回いちばん派手というわけではありません。ただ、露骨にがっかりさせられることが少ないです。速度が速く、最初の生成物の完成度も高く、ロジック、インタラクション、動き、小さなゲームのような総合課題に強いです。

Claude Opus 4.7 は性格がかなり違います。最大の強みは安定感そのものではなく、ページの雰囲気、UIの整理、見せ方です。出てきたものを開いた瞬間に「見た目がちゃんとしている」と感じやすいタイプです。ページの見え方を重視するなら、今でもかなり魅力があります。

Qwen 3.6 Max は、この中でいちばん見直す価値が大きいモデルです。もはや「中国系モデルとしては使える」という段階ではありません。場面によっては GPT 5.5 と出力品質で正面から比べられるところまで来ています。特にフロントエンドのページ、見た目の完成度、擬似的なリアルさの部分では、かなり存在感が出てきました。

DeepSeek V4 は、できないわけではありません。問題は安定性です。うまくいくときは普通に良く、場面によってはかなり悪くありません。ただ、良いときと崩れるときの差が、他のモデルより見えやすいです。

`GPT 5.5` は何が強いのか

普段やりたいことが次のような内容なら、

完成したWebページをそのまま出したい
動きのある小さなデモを作りたい
少しロジックのあるインタラクティブなページを書きたい
ミニゲームや複数状態のUIを作りたい
なるべく手戻りを減らしたい

GPT 5.5 はやはり最も無難な答えです。

主な強みは次の通りです。

コード生成が速い
最初の出力の usable さが高い
ロジックやインタラクションで大きな傷を作りにくい
複合課題に対して安定している

もっと直截に言うと、GPT 5.5 は「要件を投げたら、まず土台を正しく組みやすい」タイプのモデルです。
多くの人が本当に欲しいのは、どこか一項目だけで最も驚く結果ではなく、最初の版が破綻しないことです。その点では今でもかなり安心できます。

もちろん弱みがないわけではありません。

ビジュアル寄りのページでは、いちばん驚きがあるとは限らない
安定しているぶん、デザイン面での強い記憶点が薄いこともある

なので、デフォルトで一つ選ぶなら GPT 5.5 です。
ただし、それだけ見ていれば十分という話でもありません。

`Claude Opus 4.7` はどんな人に向くか

Claude Opus 4.7 の魅力は、見た目の質感にあります。

長所として出やすいのは、

UI構成がきれい
ビジュアル表現がまとまりやすい
ページにプレゼン感が出やすい
可視化やデザイン面で個性が出やすい

もしモデルにやらせたいものが次のような内容なら、

デモページ
データ表示ページ
見た目の印象が重要な小規模ページ
開いた瞬間に完成品っぽく見えてほしいもの

Claude は今でもかなり有力です。

一方で弱みもはっきりしています。

GPT 5.5 ほど安定しない
見た目はよくても、細かいロジックがずれることがある
動くけれど、肝心の体験が少し外れる場面がある

つまり Claude は、美意識の強いフロントエンド寄りの選手という感じです。
ページがどう見えるかを最優先するならかなり魅力がありますが、最初の一回でロジック事故を避けたいなら少し慎重に見たほうがいいです。

なぜ `Qwen 3.6 Max` を真面目に見るべきか

この中で、勢いの変化をいちばん感じさせるのが Qwen 3.6 Max です。

少し前まで、中国系のコーディングAIを見るときは「そもそも追いつけるか」が主な論点でした。今の Qwen 3.6 Max では、問いそのものが変わっています。
フロントエンド寄りの直出しタスクで、海外トップモデルと正面から比べられるか。

今の強みはおおむね次の通りです。

ページの見た目が良い
動きや擬似的なリアルさをうまく出せる場面がある
出力に完成感がある
場面によっては GPT 5.5 にかなり近いところまで行く

これは大きいです。
Webページ、フロントエンド、見せるための出力が中心なら、Qwen 3.6 Max はもはや単なる予備候補ではありません。十分に主力候補として扱えます。

もちろんまだ弱みはあります。

インタラクション寄りのロジック課題では完成度が少し落ちることがある
かなり見栄えのいいページもあれば、急に平凡に感じる課題もある
ばらつきはまだ GPT 5.5 より大きい

それでも、今いちばん注目すべき中国系モデルはどれかと聞かれたら、Qwen 3.6 Max を外すのは難しいです。

`DeepSeek V4` は今どの位置にいるか

DeepSeek V4 の立ち位置は少し複雑です。

問題は、できないことではなく、どの水準で出てくるか読みづらいことです。
ちゃんと作れるときは、見た目も機能もそこそこ悪くありません。ですが、アニメーション、ロジック、データ表現を同時に求めるような課題になると、崩れやすさが出ます。

今の印象をまとめると、

能力はある
弱いわけではない
課題によっては普通に提出できる
ただし安定性はまだ心許ない

だから向いている人もはっきりします。

何度か試すことを気にしない人、たまにやり直しが入ってもいい人、自分でコードを見て直す前提の人なら、DeepSeek V4 はまだ十分使えます。
ですが、とにかく手間を減らしたい人、最初の一回の成功率を重視する人には、まだ最適解とは言いにくいです。

普通のユーザーは結局どう選ぶべきか

モデル比較そのものが目的ではなく、実際に作業を進めたいなら、用途で選ぶのがいちばん簡単です。

1. 手間を減らして、一回目の成功率を上げたい

GPT 5.5 を選ぶ。

「要件を渡すから、まず使える一版を返してほしい」という流れに最も向いています。
何度もやり取りしたり、細かく修正したりする時間がないときほど、その総合的な安定感が効いてきます。

2. ページの見た目や仕上がりを重視したい

Claude Opus 4.7 を選ぶ。

より完成品っぽく見えるページが欲しいなら、あるいはデモや見せるための制作が中心なら、Claude の長所はかなり分かりやすく出ます。

3. 中国系で最も強いフロントエンド直出し能力を見たい

Qwen 3.6 Max を優先する。

もう「妥協して使う」段階ではありません。正面から比べる価値があります。
タスクがWeb、動き、見た目重視に寄るなら、かなり現実的な選択肢です。

4. ばらつきを許容しつつ、中国系の総合力を追いたい

DeepSeek V4 を見続ける。

能力不足ではなく、出力の揃い方がまだ弱いという段階です。
この先、安定性が改善されれば、存在感はもっと強くなるはずです。

最後に一言

今の主流コーディングAIの差は、もう「書けるか、書けないか」ではありません。
「どれがより安定しているか」「どれがより見た目に強いか」「どれが自分の仕事に合っているか」の差です。

いちばん手堅い答えが欲しいなら、まだ GPT 5.5 が第一候補です。
見た目の仕上がりやプレゼン感を重視するなら、Claude Opus 4.7 はまだかなり魅力があります。
中国系の中で今いちばん真面目に見るべきものを挙げるなら、Qwen 3.6 Max はかなり前の位置にいます。
DeepSeek V4 は、まだ安定性を伸ばしている途中の有力選手という印象です。

最短でまとめるなら、

安定性なら GPT 5.5、見た目なら Claude、中国系で最も注目すべきは Qwen 3.6 Max。

なぜイーロン・マスクとSpaceXはCursorの600億ドル買収オプションを押さえたのか

Tue, 28 Apr 2026 21:45:47 +0800

見出しだけを見ると、この話はひとことで誤解されがちです。イーロン・マスクがSpaceXに600億ドルでCursorを買わせようとしている。

ですが、本当に重要なのは600億ドルという数字そのものではありません。重要なのは、SpaceXが手に入れたのが 買収オプション であって、今すぐ完了する買収ではないことです。

この差はかなり大きいです。

簡単に言えば、SpaceXはいま将来の選択権を押さえています。今年後半に、600億ドル でCursorを買うこともできるし、100億ドル を支払って協業をさらに進めることもできます。この設計自体が、イーロン・マスクとSpaceXが求めているのは単なる財務取引ではなく、まず組み、結果を見てから完全に取り込むかどうかを決める 形だと示しています。

01 なぜ今すぐ買わないのか

もしイーロン・マスクとSpaceXが本当にCursorを手に入れたいだけなら、いちばん単純なのは最初から買収交渉をまとめることです。

それをしなかったということは、まだいくつか確定しきっていない要素があるということです。

Cursorという製品が本当に高成長を維持できるのか
SpaceXとxAIの計算資源が、Cursorを次の段階まで本当に押し上げられるのか
両社を近く結びつけたときの相乗効果がどこまで出るのか
いまこの時点で600億ドルを確定させるのが、どちらにとっても早すぎないか

だからこそ、このオプションの意味ははっきりしています。いちばん大事な権利は先に押さえるが、今日すぐ全額を払いにいかない。

イーロン・マスクとSpaceXにとっては柔軟性が残りますし、Cursorにとっても今すぐ完全に飲み込まれるより余地が残ります。

02 イーロン・マスクとSpaceXが見ているのはCursorそのものだけではない

公開されている情報から見ると、Cursorが魅力なのは人気のAIコーディング製品だからというだけではありません。いくつか非常に重要な要素を同時に持っているからです。

すでに成熟した開発者向けの入口を持っている
もっとも熱いAIコーディング領域で立ち位置を確保している
実際のエンジニアリング現場の利用データをモデルや基盤に返せる

もっと率直に言えば、イーロン・マスクとSpaceXが見ているのは単なるエディタの殻ではなく、次のようなものです。

開発者向けの配布チャネル
価値の高いユーザー層
AIコーディングの本番的な利用データ

xAIのようにAnthropicやOpenAIを追っている陣営にとって、こうした入口は非常に高価な意味を持ちます。

この段階の大規模モデル競争は、もはや「誰のベンチマークが高いか」だけではありません。重要なのは、

誰が実際のワークフローに近いか
誰が開発者の日常に入り込めるか
誰がより質の高い相互作用データを集められるか

という点です。

Cursorはまさにその入口です。

03 なぜ普通の協業契約ではなくオプションなのか

もし目的が協業だけなら、普通の提携契約でも十分なはずです。では、なぜわざわざ 600億ドル の買収オプションを付けるのか。

それは、普通の提携契約では解決できない問題が2つあるからです。

1. 他社に持っていかれるのを防ぐため

Cursorの価値は、今日の売上だけではありません。今後数年でより大きなプラットフォームに育つ可能性にあります。

もしSpaceXが単に組むだけで権利を押さえなければ、うまくいったあとに最も苦しくなるのはマスク側かもしれません。

協業で製品が伸びる
協業で成長が加速する
協業で評価額が上がる
そして最後は別の巨大企業に持っていかれる

買収オプションはまさにこの問題を防ぐためのものです。
今すぐ買わなくても、優先的に選べる権利は先に取る、というわけです。

2. 評価額の争点に緩衝地帯を作るため

もし今すぐ本格的な買収に入れば、最大の論点のひとつは単純です。600億ドル は高すぎるのかどうか。

これは今の時点ではとても答えにくい問題です。Cursorはまだ急速に変化している段階にあるからです。

今日の感覚では600億ドルは高い
しかし計算資源が補われ、モデル性能が上がり、ユーザー拡大が続けば、数か月後には違って見えるかもしれない

だからオプションは典型的な折衷案になります。

今日、価格の枠組みだけは押さえる
明日、協業の結果を見て実行するか判断する

これは、資本戦略と事業戦略が強く結びつく場面でよく見られるやり方です。

04 なぜCursor側も応じるのか

Cursorの立場から見ても、そこまで不思議な話ではありません。

Cursorが今もっとも必要としているのは、単純なお金そのものではなく、むしろ より大きな計算資源、より多い学習資源、そしてより強い戦略的な堀 である可能性が高いからです。

公開情報でも、Cursorは学習をさらに前に進めたいが compute に制約されているとされています。マスクのエコシステムにあるSpaceX / xAIと組めば、より大きなインフラに直接つながれます。

それがCursorにもたらす意味はかなり実務的です。

モデル学習をさらに拡張できる
製品能力をより速く引き上げられる
外部の大手モデル供給者に完全依存し続けなくて済む

ここはかなり重要です。

Cursorは人気のAIコーディング製品ですが、長期的には構造的な問題も抱えています。
AnthropicやOpenAIのような企業と協力しながら、同時に製品レイヤーでは直接競争しているからです。

この関係は本質的に不安定です。

そこに対して、マスクのSpaceX / xAIが示しているのは別の道です。上流のモデル層と下流の製品層を、より深く一体化させる道です。

だからCursorがこのオプションを認めたのは、価格が魅力的だからだけではありません。より重い計算資源と、より深い戦略的な結びつきを本当に必要としているからでもあります。

05 なぜ100億ドルの別ルートも残したのか

ここは特に面白い部分です。

公開されている枠組みは、「買収するか、何もないか」ではありません。「600億ドル で買収するか、100億ドル で協業をさらに進めるか」です。

これは、両者が最初からひとつの前提を共有していることを意味します。
たとえ最終的に買収しなくても、協業そのものに十分な価値がある。

この 100億ドル の選択肢は、中間状態のようなものです。

協業が非常にうまくいけば、そのまま買収へ進む
協業は有効だが、まだM&Aのタイミングではないなら、より重い戦略提携として継続する

つまり、イーロン・マスクとSpaceXはこれを「買うか買わないか」という二択にしていません。あえて中間の逃げ道を残しています。

それはたいてい、AI市場の変化が速すぎて、今日の時点で不可逆な判断をするのが最適とは限らないと、両者が理解していることを示します。

06 マスクとSpaceXの視点では、これは上場前の布石に見える

外から見ると、この動きには資本市場上の意味もかなりはっきりあります。

公開報道では、SpaceXは将来のIPOを見据え、単なるロケット・衛星企業ではなく、より強いAIストーリーを市場に見せたいとされています。イーロン・マスクにとっても、これは近年の一貫した方向性と合っています。ロケット、計算資源、モデル、配布導線、そして開発者ワークフローを、より大きな技術地図としてつなげようとしているからです。

その文脈では、Cursorは単なる事業資産ではなく、物語上の資産でもあります。

SpaceXは大規模なインフラと計算資源を持つ
xAIはモデルとAIプラットフォームの物語を持つ
Cursorは開発者導線とホットなアプリケーション層のユースケースを持つ

この3層がつながると、「モデルもやっています」という話よりずっと完成度の高いストーリーになります。

だからこのオプションは、将来の物語の線を先に押さえておく動き とも読めます。マスクにとっては、単なる契約設計ではなく、AIコーディングの入口を前もって押さえる行動でもあります。

内部統合の時間を確保しつつ、外部には「SpaceXはAIインフラだけで止まらず、アプリケーション層や開発者ワークフローにも入りたい」というシグナルを送っているわけです。

07 ひとことでまとめると

イーロン・マスクとSpaceXがCursorに対する 600億ドル の買収オプションを求めたのは、今日ただちに会社全体を飲み込みたいからではありません。開発者への入口と将来の買収権を今のうちに押さえつつ、M&Aリスク、評価額リスク、統合リスクを今すぐ全部は引き受けたくないからです。

だからこそ重要なのは 600億ドル という数字より、「オプション」という言葉のほうです。
これはSpaceXが一発の買い物をしたいのではなく、まず位置を押さえ、協業を試し、その後に完全取り込みを決めるというやり方を取っていることを示しています。

DeepSeek V4 Pro と GPT-5.5 を比較：フロントエンド・文章作成・コード実測で見えた想像以上の差

Sat, 25 Apr 2026 11:12:00 +0800

DeepSeek V4 Pro と GPT-5.5 の比較は、最近ますます話題になりやすくなっています。もはや問題は「使えるかどうか」ではなく、フロントエンド、文章作成、コードという3つの高頻度な場面で、どちらが主力として向いているのかに移っています。

この手の比較では、まず「どちらが強いのか」と聞きたくなりがちです。
しかし本当に価値があるのは、たいてい別の問いです。実際のタスクの中で、どちらがより安定し、コミュニケーションコストが低く、そのまま次に進める成果を出しやすいのか。

まず結論を簡単に言えば、だいたい次のように考えられます。

よりバランスの取れた出力や、完成度の高いプロダクト体験を求めるなら、多くの人はまず GPT-5.5 を見る
中国語環境での高頻度な反復、コスト意識の高さ、応答スピードを重視するなら、DeepSeek V4 Pro は有力な候補になる
実際の体験を決めるのは、モデル名そのものよりも、タスクの種類、プロンプトの与え方、そしてその後も修正を続けるかどうかであることが多い

以下、代表的な3つの比較シーンに分けて見ていきます。

1. フロントエンドタスク：見るべきは「ページを書けるか」ではなく、「その後も直し続けられるか」

フロントエンド作業は、結果が目に見えやすいため、モデル比較に向いているように見えます。
ページが動くか、見た目が良いか、構造が整理されているかは、すぐに判断できます。

しかし本当の差は、最初の版が書けるかどうかよりも、むしろ次のような点に現れます。

構造は十分に明確か
コンポーネント分割は自然か
一か所を直したときに別の場所まで壊れないか
複数ラウンドの指示でも同じ実装方針を保てるか

だからこそ、初回の見た目が派手なフロントエンドデモでも、実際のワークフローに入れると必ずしも優位とは限りません。

たとえば次のようなタスクなら、

動くページのプロトタイプを素早く作る
ランディングページの案をまず形にする
必要なスタイル、ボタン、カード、フォームなどを埋める

どちらのモデルでもかなり近いところまでは持っていけることが多く、差は出力スタイルに現れやすいです。

しかしタスクが次のように変わると、

UI を何度も継続的に修正する
既存コードを読みながら続きを直す
コンポーネント構成、スタイルの一貫性、保守性を同時に考える
静的ページから実際のプロジェクトコードへ段階的に進める

見るべき点は「初回でどちらが見栄えが良いか」ではなく、「5ラウンド後でもどちらが崩れにくいか」になります。

つまりフロントエンド比較で本当に見るべきなのは、ページを生成できるかどうかではありません。制約を追加し続けても、構造の安定性、命名の一貫性、修正コストの低さを保てるかどうかです。

2. 文章作成タスク：比べるべきは文字数ではなく、文体の安定性とリライトのしやすさ

文章作成は、特に見誤りやすい領域のひとつです。

というのも、最初の出力だけを見れば、どちらもそれなりによく見えることが多いからです。
構成は整い、段落もそろい、文体も滑らかで、一見すると大差がないように感じます。

しかし、そこで一歩先まで進めると差が出てきます。

想定読者を正確に理解できるか
同じテーマで文体を切り替えられるか
リライト時に元の要点を落とさないか
要約、膨らませる作業、タイトル変更、構成変更でも安定しているか

文章作成で怖いのは「書けないこと」ではなく、「書けたように見えるのに、結局かなり直す必要があること」です。

そのため、DeepSeek V4 Pro と GPT-5.5 を比べるときは、単に1本ずつ記事を書かせるより、次のような連続テストのほうが実用的です。

まず初稿を書く
別のトーンで書き直す
もっと短い版に圧縮する
クリックを取りやすい見出し向け、あるいは検索流入向けに組み替える

その数ラウンドでも要点が散らず、表現がぶれず、構成が崩れないなら、そのモデルは実際の文章作成ワークフローでより高い価値を持ちます。

つまり文章作成で本当に比べるべきなのは「文才」ではなく、リライト能力、指示への従いやすさ、継続的な協業感です。

3. コードタスク：本当の差は長い作業チェーンでの安定性に出る

コード関連の作業は、フロントエンドよりもモデルの実力を露呈しやすい分野です。なぜなら、単に出力するだけではなく、現実のプロジェクトと接続しなければならないからです。

すぐに次のような問題にぶつかります。

既存のプロジェクト構造を理解できるか
複数ファイルを同時に修正できるか
修正後に新しい問題を持ち込まないか
エラーやログを追ってデバッグを続けられるか
数ラウンド後でも、すでに何をやったか覚えているか

この種のタスクでユーザーが本当に気にするのは、単体のコード片が美しいかどうかではありません。作業を継続的に前へ進められるか、それとも後片付けを自分がしなければならないのかです。

だから DeepSeek V4 Pro と GPT-5.5 を比較するとき、本当に見るべきなのは単発のコード問題ではなく、次のような実務に近い流れです。

既存のリポジトリを読む
バグを見つける
関連する複数ファイルを修正する
エラーに基づいてさらに直す
最後に結果を整理して説明する

タスクがこのような連続進行型になるほど、コンテキスト保持力、実行の癖、説明の質、手戻り率は、単発の回答品質よりも重要になります。

そのため、コード作業では「ずっと1つのモデルだけを使う」という形ではなく、タスクの段階によって主力を切り替えるユーザーが多くなるのです。

4. 本当に比べるべきなのは勝敗ではなく、「どの種類のタスクを誰に任せると得か」

DeepSeek V4 Pro と GPT-5.5 を並べて、ただ総合チャンピオンを決めようとしても、結局は中身の薄い結論になりがちです。

現実のタスクは同じ問題ではないからです。

単発生成もある
複数ラウンドの協業もある
中国語での文章作成もある
エンジニアリング変更もある
速度重視もある
安定性重視もある
コスト重視もある

だから、実際の使い方に近いのは、タスクの目的ごとに考えることです。

より完成度の高い総合体験、成熟した対話、安定した汎用出力を求めるなら、まず GPT-5.5
中国語環境で高頻度に試行錯誤し、素早く反復し、費用対効果も重視するなら、DeepSeek V4 Pro を本格的にワークフローへ入れる価値がある
タスク自体が長いチェーン、多段階修正、複数人協業なら、初回結果だけで判断せず、5ラウンド後も安定しているかを見るべき

言い換えれば、本当に問うべきなのは「どちらが絶対的に強いか」ではなく、
フロントエンド、文章作成、コードという3種類のタスクで、いまの自分にとってどちらがより手になじむ道具かということです。

5. ちゃんと意味のある比較をするには

自分で DeepSeek V4 Pro と GPT-5.5 を試すなら、1ラウンドだけで判断するより、次のようなやり方のほうがずっと信頼できます。

両方に同じ初期要件を与える
制約条件をそろえる
3〜5ラウンド連続で追質問する
出力品質、脱線回数、手戻り量を記録する
最後に速度、コスト、最終的な使いやすさを比較する

こうして得た結果のほうが、「最初にどちらが派手だったか」よりも、実際の仕事に近い判断材料になります。

特にフロントエンド、文章作成、コードのような分野では、体験を決めるのはスタートの派手さではなく、最後まで一緒に仕事を進められるかどうかです。

6. まずはこう覚えておけばよい

ひとまず使える形で覚えるなら、次のようにまとめられます。

GPT-5.5：総合型で、製品として洗練された、標準的な作業台に近い
DeepSeek V4 Pro：中国語環境や高頻度な試行錯誤で、日常ワークフローに入れる価値が高い競争相手
本当の比較ポイント：初回の派手さではなく、複数ラウンド後の安定性と手間の少なさ

この種の比較で本当に重要なのは、決して「誰が勝ったか」だけではありません。
自分のフロントエンド、文章作成、コードのタスクにおいて、どちらを使うと継続的に前へ進みやすく、手戻りが少なく、安定して成果を出せるかです。

ChatGPT・Claude・Gemini の役割分担はどうするべきか：日常会話、コーディング、特殊機能の選び方

Sat, 25 Apr 2026 10:51:19 +0800

今では、多くの人が1つのモデルだけを使うのではなく、ChatGPT、Claude、Gemini を行き来しながら使っています。そうなると問題はかなり実務的になります。どんなタスクを、どのモデルに任せるべきなのか。

この点が悩ましくなるのは、3社とも弱いからではありません。むしろ十分に強くなった結果、それぞれの得意分野が分かれてきたからです。いまだに「どれがいちばん賢いか」のような曖昧な基準で選ぶと、かえって外しやすくなります。

まずは簡略版の結論から言うと、おおむね次のように考えられます。

日常会話や汎用タスクなら、まず ChatGPT を思い浮かべる人が多い
コマンドラインでのコーディング、長いコンテキストでの協業、継続的に進めるタイプの作業なら、Claude のほうが扱いやすいことが多い
Google エコシステム、検索、マルチモーダルの入口、あるいは一部の製品レベルの特殊機能が必要なら、Gemini の存在感が強い

以下、3つに分けて見ていきます。

1. 日常会話：なぜ多くの人がまず `ChatGPT` を開くのか

多くの一般的な利用シーンでは、ChatGPT は今でも「標準の入口」のような存在です。

ここで言いたいのは、特定の benchmark の話ではなく、全体的な使い心地です。
ちょっとした質問をしたいとき、考えを整理したいとき、短い文章を書きたいとき、たたき台を作りたいとき、資料を要約したいときに、ChatGPT は全体としてバランスがよく感じられます。

強みは主に次の点にあります。

回答スタイルが比較的安定している
一般ユーザーにとって使い始めるハードルが低い
多くの総合タスクで過度な追加調整がいらない
製品としての完成度が高く、日常的に高頻度で使いやすい

たとえば次のような作業なら、

あるテーマを整理してほしい
アイデアを構造化された内容にまとめたい
長文を要約したい
いくつかの案をブレインストーミングしたい
表現をより分かりやすく整えたい

ChatGPT はかなり自然な出発点になります。

これは、あらゆる専門タスクで必ず最強だという意味ではありません。むしろ「広く汎用的に使える」という点で、標準の作業台に近いということです。

2. コマンドラインでのコーディングと長いタスク：なぜ `Claude` を好む人が多いのか

タスクが「少し会話する」段階から、「最後まで継続して進める」段階に移ると、多くの人の好みは Claude に傾き始めます。

特に次のような場面です。

コマンドラインでのプログラミング
大規模プロジェクトのコンテキスト理解
複数ファイルをまたぐ修正
長い流れのデバッグ
コードを読みながらタスクを前進させる作業

こうしたタスクで重要なのは、1回の返答がどれだけ派手かではなく、長い作業の流れの中で安定していられるかどうかです。

Claude が好まれる理由は、「ひとことが他よりうまいから」ではなく、主に次の点にあります。

長いコンテキストのタスクでも粘り強い
ファイル、ログ、ルールを連続して読むときの安定感が高い
複雑なコーディング作業を段階的に進めやすい
コマンドラインや agent ワークフローでは主力モデルとして扱われやすい

vibe coding、コマンドラインでのバグ修正、プロジェクト構造の理解、複数ファイルにまたがる機能改修をしているなら、Claude の強みはより見えやすくなります。

要するに、Claude は一問一答のためだけでなく、一緒に「作業を進める」相手として向いているモデルだと言えます。

3. `Gemini` の強みは「何でも正面から勝つこと」ではない

Gemini を語るとき、多くの人は「結局3つの中で最強なのか」と聞きがちです。

しかし実際の利用感覚からすると、もっと有用な問いはそこではありません。どんな場面で、あえて単独で使う価値が高いのか。

Gemini の価値は、主に次の方向で表れやすいです。

Google エコシステムとの連携
検索や情報収集
マルチモーダルの入口
一部の製品機能との連動

もし普段のワークフローがもともと Google のツールチェーンに近いなら、たとえば

検索
ドキュメント
メール
ブラウザ上での利用
モバイル側の入口

Gemini の実用上の便利さは、単純なモデル性能の比較よりも重要になるかもしれません。

つまり Gemini の使いやすさは、「どこで自分のワークフローに自然につながるか」から来ることが多く、「単発の回答で誰に勝つか」だけでは測れません。

4. 本当に役立つ選び方は、最強を問うことではなく、タスクの種類を問うこと

3つのモデルを並べて比較するとき、いちばん陥りやすい罠は「唯一の最強」を探そうとすることです。

ですが、現実のタスクはあまりにも違います。

単発のQ&Aもある
長い対話で伴走してもらうものもある
コードベースを扱う作業もある
情報検索もある
マルチモーダル処理もある
ツールチェーンとの協業もある

だからこそ、より有効なのはタスクの種類で分けることです。

総合型で、日常的に高頻度に使えて、開けばすぐ使える助手がほしいなら、まず ChatGPT
長いコンテキスト、コマンドライン、コーディング協業、複雑な作業の継続的な前進が必要なら、まず Claude
Google エコシステム、検索、マルチモーダルの入口、あるいは一部の製品連携を活かしたいなら、Gemini を重視する

このような役割分担のほうが、無理に総合優勝を決めるより、実際の使い方に近いです。

5. なぜヘビーユーザーは3つとも契約するのか

ライトユーザーの視点では、3つ全部に課金するのは重複して見えがちです。
けれどもヘビーユーザーの視点では、それは異なる仕事に異なる道具を割り当てているだけです。

理由は単純です。
3つのモデルの強みがすでにはっきり分かれ始めているなら、同時に使うことは重複課金ではなく、タスク切り替えのコストや試行錯誤のコストを下げる方法だからです。

たとえば、

日常的な整理や総合Q&Aには ChatGPT
コーディングの主作業には Claude
検索、マルチモーダル、Google 関連の導線には Gemini

この組み合わせの考え方は、デザイナーが複数のソフトを入れることや、開発者が複数の IDE を使うことと本質的には変わりません。

6. 何度もモデルを切り替えすぎないほうがいい場面

もちろん、モデルが多ければ常に良いわけではありません。

まだ安定したワークフローを作っている途中なら、3つのモデルを早い段階で頻繁に行き来すると、かえって混乱しやすくなります。よくある問題は次の通りです。

同じタスクを何度も説明し直す
モデルごとに違う提案が出て、判断が難しくなる
コンテキストが途切れ、協業コストが上がる
自分なりの使い分けができる前に、道具選びそのものに引っ張られる

なので、より安定したやり方は次の通りです。

まず各モデルに1つずつ主な担当領域を与える
その担当領域でしばらく続けて使う
そのうえで自分なりの使い分けを徐々に作っていく

こうすることで、「今日はこれを試してみよう」という段階に留まり続けるのではなく、再利用しやすい実践知を得やすくなります。

7. まずはこう覚えておけばいい

とりあえず使える覚え方だけ欲しいなら、次のような口語的な分担表で十分です。

ChatGPT：汎用型の標準アシスタント
Claude：長いタスクとコーディング協業の主力
Gemini：検索、マルチモーダル、Google エコシステムで強みを発揮しやすいツール

これは絶対的なルールではありませんし、3者が互いに代替できないという意味でもありません。あくまで実際の利用感覚に近い出発点です。

本当に重要なのは、「宇宙最強のモデル」を選ぶことではなく、できるだけ早く次を見極めることです。
今、目の前のこの種類のタスクに対して、どのモデルがもっとも時間を節約し、気力を消耗させず、結果につながりやすいか。

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

をきちんと組めるようになると、あなたとモデルの協業品質はかなり大きく上がります。

毎回ゼロから「自分が誰で、どう働いて、何をしてはいけないか」を説明し直す必要がなくなり、それらが環境の一部として定着するからです。

それこそが、強いモデルを本当に成熟した道具として使うための重要な一歩です。

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

VS Code に Claude を接続する: API 設定からページ生成まで

Thu, 16 Apr 2026 17:47:17 +0800

大規模言語モデルを日常の開発に取り入れ始めると、最初に変わるのは「コードが書けるかどうか」よりも、「細かく散らばった作業をまとめて前に進められるかどうか」です。

こうしたツールの価値は、数行補完してくれることだけではありません。エディタの中で対話しながら、ファイルを編集し、結果を確認し、そのまま次の修正に進めることにあります。簡単なページ作成、プロトタイプ検証、見た目の調整、小さな機能追加では、この流れのほうが手作業で行き来するより自然に感じられることが多いです。

この記事では、VS Code に Claude 系モデルを接続したあと、実際にページ生成や小さな機能改善へどう活かすかを整理します。

1. まずはツールチェーンをつなぐ

この種の AI コーディングプラグインの基本的な流れはだいたい同じです。

VS Code に対話型コード編集に対応したプラグインを入れる
モデルサービスの Base URL を設定する
自分の API Key を登録する
使用するモデル名を選ぶ

ここまで終わってはじめて、エディタ内の AI 機能が実用段階に入ります。その後の使い勝手の差は、「使えるかどうか」よりも、「モデルの品質はどうか」「対話の体験が自然か」「生成結果が安定しているか」に出やすいです。

初めて設定する場合は、次のように考えると分かりやすいです。

プラグインは自然言語の依頼をエディタ上の操作に変換する
API はその依頼をモデルサービスへ送る
モデルは意図を解釈してコードや修正案を返す

つまり、実際に合わせるべき要素は、プラグイン、接続先 URL、モデル名の 3 つです。

2. 最初は小さなタスクから始める

最初から「丸ごと 1 つのプロジェクトを作ってほしい」と考える人は多いですが、期待値をうまく作るには、むしろ小さなタスクから始めるほうが現実的です。

たとえば:

シンプルなフロントエンドページを作る
既存ページにお知らせ欄を追加する
登録フォームを足す
UI を少し整えて、より正式な見た目にする

こうしたタスクが向いている理由は次の通りです。

指示が明確で、モデルが理解しやすい
結果をすぐにプレビューできる
対話とコード修正の連動が見えやすい

要求が具体的であれば、プラグインはサイドバーで会話しながら、同時にファイルも編集してくれます。その後で結果を見て、ページを確認し、次の要望を足す。このリズムは、単なるチャットより実際の作業に近いものです。

3. 本当の効率化は一発生成ではなく継続的な反復にある

AI コーディングで誤解されやすいのは、「最初の生成結果がどれだけすごいか」に意識が寄りすぎることです。

実際に重要なのは、2 回目、3 回目の修正でもちゃんと前に進めるかどうかです。

よくある流れはこうです。

まず動くページの土台を作らせる
そのあとで 1 つか 2 つ機能を追加する
コードと UI が一緒に整っていくかを見る

ツールの体験が良ければ、とても仕事の速いジュニア開発者と組んでいる感覚に近くなります。

こちらが要件を伝える
まず 1 版目が出る
足りない点を指摘する
そのまま修正が続く

こうした対話ベースの反復こそが、実際の開発に近く、効率差が出やすい部分です。

4. AI に任せる部分と自分で直したほうが早い部分を分ける

ここもかなり大事です。

ページレイアウト、コンポーネントの初稿、フォームの骨組み、スタイルの整え、仮の文言、繰り返しが多いコードは、AI に任せやすい領域です。

一方で、次のような小さな変更だけなら:

ボタン文言を 1 行変える
フッターの説明を少し直す
ほんの小さなスタイルを調整する

自分でその場で直したほうが速いことが多いです。そこまで小さい変更なら、改めてモデルに依頼するコストのほうが大きくなりやすいからです。

効率のよい使い方は、「全部 AI に任せること」ではなく、「大きな塊は任せる、小さな仕上げは自分でやる」と切り分けることです。

5. API 設定は最初の壁だが、本質的には難しくない

つまずく人の多くは、コーディングそのものではなく設定で止まります。

確認すべき点はだいたい次の通りです。

接続先 URL が正しいか
キーが有効か
モデル名がサービス側と一致しているか
プラグインが特定の Base URL 形式を要求していないか

このどれかがずれると、プラグイン自体は開いていても、実際のリクエストだけ失敗することがあります。

そのため、うまく動かないときの確認順としては:

URL を確認する
キーを確認する
モデル名と URL 形式を確認する

この順番で見れば、多くの接続トラブルは素早く切り分けられます。

6. 生成結果を使い続ける価値があるかどうか

見るべきなのは「派手かどうか」ではなく、次の点です。

生成されたページがすぐ動くか
構造がある程度わかりやすいか
追加の指示を出しても大きく逸れないか
修正範囲が広がっても一貫性を保てるか

1 回か 2 回の往復で、真っ白な状態から「ここから育てられるページ」まで進むなら、そのツールには十分な実用性があります。

逆に毎回大きく手直しが必要なら、効率化ではなく、単に「コードを書く」作業が「コードをレビューする」作業に置き換わっているだけです。

まとめ

VS Code で Claude 系モデルを使う魅力は、「もうコードを書かなくてよくなること」ではありません。散らばっていて反復的で、思考を止めやすい作業をまとめて前に進められることです。

より現実的な使い方は次のような形です。

まず AI にページや機能の土台を作らせる
2 回か 3 回の対話で磨き込む
最後の細かな確定修正は自分で行う

この形なら、AI は開発をすべて置き換える存在ではなく、作業を加速する相棒として機能します。

AIコーディング on KnightLiブログ

GitHub AIオープンソースプロジェクト分類：Coding AgentからRAGナレッジベースまで

カテゴリ概要

AIコーディングとCoding Agent

Agentスキルとワークフロー

RAG、ナレッジベース、メモリ

マルチモーダルとコンテンツ制作

ローカルモデルと推論

垂直アプリケーションと自動化

AIアプリ開発基盤

Gemini 3.5 発表：Flash が先行し、Google は Agent と長時間タスク実行に重点

Gemini 3.5 Flash が先行

焦点は Agent とコードタスク

マルチモーダル UI とグラフィック能力の強化

企業用途：時間のかかるワークフローを自動化する

Gemini Spark：個人向け AI Agent

安全対策も前段に移る

Gemini 3.5 をどう見るか

agentmemory：Claude Code、Codex、Cursorに永続メモリを持たせる

何を解決するのか

対応するAgent

クイックスタート

静的なメモリファイルとの違い

典型的な用途

注意点

向いている人

まとめ

Gemini 3.5 Pro がリーク：コードネームは Cappuccino、Google はコーディングと Agent で巻き返しを狙う

まず結論

Cappuccino とは何か

なぜコーディング能力が焦点なのか

Google がコーディングを急ぐ理由

Spark は 3.5 Pro より重要かもしれない

一般ユーザーにとっての意味

開発者にとっての意味

今このニュースをどう読むべきか

まとめ

Codex が ChatGPT モバイルからのリモートアクセスに対応、Enterprise ワークスペースで Access Tokens が利用可能に

今回の更新内容

モバイルリモートアクセスが解決する問題

開発者にとっての価値

Access Tokens が解決する問題

普通の API key ではない

安全な初期設定：Remote Control はデフォルトでオフ

利用前に必要な更新

企業での Codex 利用への影響

注意すべき境界

まとめ

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

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

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

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

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

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

どう使うとよいか

まとめ

DeepSeek-TUI：DeepSeek V4をターミナル上のコーディングAgentにする

DeepSeekの利用入口を補う

長いタスクには純粋なCLIよりTUIが向いている

Autoモードは境界が明確なタスクに向く

サブAgentの意味はタスク分割にある

1Mコンテキストは万能ではないが、プロジェクト理解には役立つ

向いているユーザー

注意すべきリスク

まとめ

API Key を GitHub に push しないために：AI コーディング時代のシークレット漏洩対策

初心者が Key を漏らしやすい理由

.gitignore は飾りではない

Key を push したら、ファイル削除だけでは安全にならない

フロントエンドに本物の Key を置いてはいけない

Vibe Coding でも安全責任は消えない

今すぐ確認すること

参考資料

GPT-5.5、GPT-5.4、GPT-5.3-Codex はどう使い分けるべきか

3 つのモデルの位置づけ

用途別にどう選ぶか

クレジット消費はどれくらい違うか

Codex での利用制限の違い

よくある場面ではどう選ぶか

1. 日常の Q&A、資料整理、長文要約

`.gitignore` は飾りではない