6 つの AI コーディング CLI を半年使って悟ったこと：モデルがどんなに強くても、仕事には監督が必要

2026 年、ターミナルに AI コーディングツールをいくつも入れていない人はいません。Claude Code、Codex CLI、opencode、pi、omp——そして最近は DeepSeek が公式ハーネスまで出しました。私は全部入れています。しかも半年間、本気で使い込んでいます。

結論は最初に 2 つだけ。

1 つ目、悪いツールはなく、合わない使い方があるだけ。1 つのツールに全部やらせるのが最大の無駄。

2 つ目、モデルがどんなに強くても、仕事には監督が必要。しかも独立した第三者であるべき。

以下、私の実際の使い方をベースに、6 つの CLI をひとつずつ掘り下げます——何が得意か、どこが弱いか、どの場面でどれを出すか。

6 つのツールをひと目で

ひとつずつ掘り下げる：優劣と使用シーン

Claude Code：コーディングの主力

真面目な開発の 9 割はこれで行きます。skills・subagents・hooks・/code-review というエコシステムは 6 つの中で最も成熟していて、主体性も最強——ゴールを与えれば、コードを読み、テストを実行し、計画から実装まで一気に進めます。20+ ファイルの大規模リファクタでは、全体把握力が頭ひとつ抜けています。

代償も現実的です。トークンを猛烈に消費し、割り当てに悩まされ、アカウント風控の厳しさは有名で、"CC が凍結された"系のネタは本が書けるほど。私のルールは重要なタスクはこれ、些細なタスクは他で。

Codex CLI：切り込み隊長にして厳格なレビュアー

"寡黙で確実"が全てです。高推理強度モードのデバッグは圧倒的で、Reddit には「3 つのバグを一度に全部直した」という報告も。私の実感も同じ——余計なことをせず、指示を実行して検証まで終えます。コスト管理も良く、同じ仕事でのトークン消費は Claude より明らかに少ない。

CR も得意です。Reddit の例えが的確——「Claude は全部やったと言い切るが、Codex はここもあそこもまだ直ってないと指摘する」。レビューを頼めば容赦なく、問題リストが明快に返ってきます。だから「cc max が書き、codex が審査する」というコミュニティの組み合わせがこれだけ流行っているのです。

弱点は 2 つ。1 つは遅さと"先にやる、あとで聞く"気質。要求が曖昧だと勝手に推測して進むので、目を離せません。もう 1 つはコードの趣味——問題解決は堅実なのに、書いたコードのスタイルと抽象度が今ひとつ。命名、レイヤリング、可読性といった"ソフトスキル"は明らかに Claude の方が上。だから私のルールは作らせて、審査させて、でもアーキテクチャは決めさせない。厄介なバグ、バッチ処理、サンドボックスが必要な高リスク作業には最適。頻繁な認識合わせが必要な探索的開発や、コードスタイルにこだわりが強い現場には不向きです。

opencode：万能アダプタ

SST チームのオープンソースエージェント（MIT）。最大の武器はモデル非依存——75+ プロバイダ、GLM でも MiniMax でも DeepSeek でも Claude でも GPT でも、無料モデル込みで自在に切り替えられます。TUI の操作感は主要 3 ツールで最も良いと広く言われ、Claude Code よりトークン消費も少なめ。

私の使い方はモデル試し、プロバイダ比較、予算重視のバッチ処理。どのベンダーにも縛られない自由は、慣れると病みつきになります。

pi：ミニマリスト

pi は Mario Zechner 作の意図的にミニマルなハーネスです。コアツール 4 つ、システムプロンプト約 1k トークン、15+ プロバイダ。能力の上限は追わず、速さと安さを追求——数秒で結果が出て、コストはほぼゼロ。

だから私の中での役割は明確です。最も楽な CR ツール。単一ファイル、小さな変更、数分の diff なら、pi にスタイル・潜在バグ・セキュリティ上の問題をスキャンさせます。速さと安さこそが機能——コストが十分低いので「毎回の変更でレビュー」が現実的になります。

omp：ファミリーパック

omp（Oh My Pi）は pi の"なんでも入り"フォークです。hash-anchored edits、ネイティブ LSP リファクタリング、DAP デバッグ、ブラウザ自動化、サブエージェント、60+ プロバイダ——IDE の能力を全部ターミナルに詰め込んだ感じ。

私の中での役割は複雑な PR のレビューツール。影響範囲が広い PR では、コードを実際に読み、テストを走らせ、効果を確認してから判断できるので、pi より一段上のレビュー品質。コストと速度はプレミアムモデルより現実的——バランス型の選択です。

しかも omp にはリアルタイムレビューが標準装備されています。--advisor ランタイムでレビューモデル（例：openai-codex/gpt-5.5）をアドバイザーとして設定すると、メインエージェントの毎ターンをリアルタイムで監視し、問題があれば inline メモ（concern / aside / blocker の 3 段階）を即座に注入。メインエージェントはそれを見てその場で軌道修正するか、直さない理由を説明します。レビューは後付けではなく、書くのと同時に進行する——これが omp の最も独自なカードです。

DeepSeek Harness：安くて量がこなせるレビュー機械

dsh は DeepSeek 公式のエージェントハーネス（MIT、2026 年 8 月 13 日にオープンソース化、"Everything is a Plugin"）。web / headless / tui の 3 プロファイルがあり、私は 0.1.0-rc.6 を運用中。V4 Flash と組み合わせると：1M コンテキスト、圧倒的な速度、そしてキャッシュヒット時の入力価格は $0.0028/M——ミスの $0.14/M の 50 分の 1。

ここがぶっ飛んでいる部分です。無給のレビュー労働者になれるほどの安さ。キャッシュフレンドリーな設計（長いセッションでコンテキストが安定し、ヒット率が上がる）のおかげで、高頻度・大量のレビューを何十回走らせても、トークン代はほぼ無視できます。

このやり方は私の発明ではない

この分業を組み立てているうちに気づきました——コミュニティの共通認識はすでにこうでした。

r/ClaudeCode では、この一文が繰り返し引用されます。「Claude は越権の罪を犯し、Codex は手抜きの罪を犯す」。だから Claude で設計、Codex で実装、互いにレビューさせる人がいる。結論は「両方使え」。X の Theo もまったく同じアドバイス——API を書き終えたら claude -p で Opus にセカンドオピニオンをもらえ。OpenAI のモデルが書くコードの品質が顕著に上がります。

中国コミュニティはもっと踏み込みます。V2EX の定番コンボ：「最終的には必ず二刀流でクロスレビュー。主力 1 つ + 入門 1 つ」。Claude Code を CC Switch で DeepSeek にルーティングして基本コーディングを安く速く済ませ、「最後の統合チェックは codex に渡す」人、Claude Code + DeepSeek V4 Pro でキャッシュヒット率 99% を報告する人も。掘金の実測記事は日常をこう描きます——「左で Cursor が書き、右のターミナルで Claude が相談役、バックグラウンドで Codex が昨日の PR をレビュー」。一主二従。これこそ 2026 年で最も現実的なワークフローだと私は思います。

今年初頭の騒動も後押ししました。Anthropic がサードパーティの Claude 呼び出しを一時ブロックし、DHH は「開発者を Claude Code に囲い込む偏執的な試み」と批判。どちらが正しいにせよ、この一件が一つのコンセンサスを強固にしました——「書く」と「審査する」を同じモデルに縛ってはいけない。

私の 3 段階レビュー体制

日常では、コストが上がる順に 3 段階でレビューしています。

第 1 段：pi —— 最速・最省のミニマルチェック。 小さな変更、単一ファイル、数分の diff。pi が数秒でレポートを返します——スタイル、潜在バグ、セキュリティ上の問題。ほぼゼロコストで十分。

第 2 段：omp —— 複雑な PR、バランス型。 影響範囲の広い PR は omp へ。コードを読み、テストを走らせ、効果を確認してから判断します。品質とコストのバランスが最良。書きながらレビューしたい場面では --advisor を有効にして、別モデルに毎ターン監視させることもできます。

第 3 段：DeepSeek Harness + V4 Flash —— 高頻度・大量・ほぼゼロコスト。 バッチレビュー、全量スキャン、週次のコード点検。dsh に任せて、何十回でも回します。

決定打：Claude / Codex で書き、dsh で審査する

半年で最も効果を感じた組み合わせ：Claude Code か Codex にコードを書かせ、そのまま dsh コマンドを実行させて、DeepSeek Harness に独立したレビューを通させる。（ちなみに omp の --advisor も同じ発想の内蔵版です——レビューモデルがメインエージェントの毎ターンをリアルタイムで監視し、書きながら審査します。）

効く理由は 3 つ。

1. 独立した第三者。 書くモデルと審査するモデルが別。自己レビューは作者が自分の審判員になるだけ——ミスはモデルの弱点領域に潜み、まさにそこを自分ではチェックできません。別モデルならエラー特性が全く違い、盲点が補完し合います。
2. キャッシュヒット率が高く、コストが実質ゼロ。 DeepSeek の KV キャッシュはプレフィックス一致。長く安定したセッションならヒット率は簡単に 95% 超（V2EX では 99% の報告も）。$0.0028/M なら何十回レビューしても痛くありません。
3. 速度こそ生産性。 V4 Flash は速く、dsh 1 コマンドで数十秒のうちにレポートが出ます。レビューが「たまに」から「毎コミット」になり、頻度そのものが品質になります。

なぜ「独立した第三者による監督」は本当に効くのか

• 自己レビューには盲点がある。 自分で書いたばかりのコードは「どう見ても正しく見える」——ここが一番危険です。
• クロス検証が取りこぼしを拾う。 2 つのモデルのミスは重なりません。A が見逃しても B が指摘する可能性が高い。
• コストの壁が消えた。 独立レビューは昔、高級モデルをもう 1 回分払う必要がありました。V4 Flash の価格が「毎コミットレビュー」をデフォルトにしました。
• コミュニティも既に実践している。 Theo の claude -p セカンドオピニオン、Reddit の 2 モデル相互レビュー、「単一ベンダーに縛られるな」というコンセンサス——独立第三者レビューは私の発明ではなく、2026 年のコミュニティの答えです。

実践のステップ

今日から： コーディングエージェントに 1 つのルールを——納品前に dsh（または別のモデル）で変更をレビューさせる。

今週中に： レビュー段階を固定する。小変更は pi、大きな PR は omp、高頻度バッチは dsh。コーディング担当は Claude Code / Codex / Qoder / Cursor のどれかに固定。

長期的な習慣： 「ライター X + レビュアー Y、ただし X ≠ Y」を徹底。どのモデルが最強かより、誰かが見ていることの方が大事です。

最後に

最高のツールはありません。あるのは仕事に合ったツールだけです。2026 年の正解は「勝者を 1 つ選ぶ」ことではなく、マトリクスを組むこと。それぞれのツールに得意なことを任せ、安くて速い独立した第三者で品質の最後の砦を守る。

モデルがどんなに強くても、仕事には監督が必要。しかも独立した第三者であるべき。