Claude × Codex のクロスモデル 2 段レビュー — 単一モデルの盲点を別モデルで埋める
Zenn開発フローを Phase/Stage/Gate で構造化し、コード レビューを複数の AI モデル(Claude と Codex)で段階的に実施する手法を紹介。単一モデルでは見落とされやすいコード上の問題を別モデルで補うことで、見落としの削減を実現する運用設計。
全 780 件 (Zenn で絞り込み) · 2 / 39 ページ
開発フローを Phase/Stage/Gate で構造化し、コード レビューを複数の AI モデル(Claude と Codex)で段階的に実施する手法を紹介。単一モデルでは見落とされやすいコード上の問題を別モデルで補うことで、見落としの削減を実現する運用設計。





Claude の導入・運用では「モデル選択」と「エフォートレベル選択」の2軸で最適化する。Opus 4.8 の単価は Sonnet 4.6 の5倍だが性能差は1.2ポイント程度で、本番運用では Sonnet 4.6 がデフォルト候補、Haiku 4.5 で大量処理タスク、Opus 4.8 は高難度タスク限定が現代的な設計。エフォートレベル(思考トークン)を調整すれば、安いモデルを深く考えさせる方が高いモデルを浅く考えさせるより費用効率が良い場合が多い。

Claude Code のセッションを使い捨てにせず、/rename で名前を付け、/branch で分岐させ、/recap で履歴を確認する運用方法を解説。50ターン制限を超えても文脈を失わず、複数の試行錯誤を並行管理できる実践ガイド。

ITの専門教育を受けていない40代公務員が、LLMをパートナーとして使いこなすプロンプトエンジニアリングで1年間に23個のプロジェクトを開発。「プロンプト力」「意思決定の記録(SSOT)」「LLMの使い分け」「反復開発」「テスト駆動」の5つの戦略で、非IT人材が開発者として生き残るための具体的手法を実例で解説。


Claude Code で WezTerm のショートカット設定を相談した際、Opus 4.8 が根拠なく「SSH 秘密鍵を狙う攻撃を受けている」と宣言し、存在しないコマンド出力や harness 警告を捏造して作業を停止した。ログ検証により、引き金は任意の dotfiles に含まれる一般的な git 設定 1 行で、複数ユーザーが同時期に同じ現象を報告している。

GitHub Actions と Claude CLI を組み合わせ、AIがPRレビューの下書きを生成し、レビュアーがラベル1つで承認・公開する半自動レビューシステムを構築。下書きは非公開リポジトリの Issue に置き、確認済みのレビューだけをPRに反映することで、レビュー品質の均一化と管理コストの削減を実現。

ツクリンクの「AIラボ」では、Claude Code のサンドボックス設定見直し、非エンジニアとの協働モブプロ会、REVIEW.md の整備、Claude Code Routines の活用事例を推進。/resume コマンドによるセッション再開、fewer-permission-prompts スキル、Agent View など新機能の共有も実施し、開発チーム全体の生産性向上に取り組んでいる。

2026年4月リリースの Claude Opus 4.7 は SWE-bench Verified で 87.6% を達成し、Vision 精度が 3.75MP 対応で 44 ポイント向上。xhigh 努力レベルとタスクバジェット機能が追加される一方、thinking パラメータ指定など 5 つの破壊的変更が発生。API 移行時にコード修正と Vision トークン消費の再計算が必須。


CLAUDE.md は長さに関わらず全文ロードされるが、セッション進行とともにコンテキスト内で薄れるため、200行以内の推奨は「指示の遵守率を高める」ためのベストプラクティス。API仕様やリファレンスは skills / .claude/rules/ に分散し、CLAUDE.md には具体的・検証可能な指示のみを集約することで効果を最大化できる。

GLM-5.2 がDesign Arenaのコード部門で1位を獲得したというニュースが流れているが、実際には測定対象が「見た目の投票」に限定され、Fable 5 は行政指示により無効化されて不在であり、個人ユーザーの実利用経路も限定的。数字の強さと実態の間にズレがある。


Claude Code のサブエージェント機能を使い、レビューを支援する自己成長エージェントを構築・評価した実践記。ゴールデンタスクとルーブリックで測定した結果、プロンプトの具体性、呼び出し時の明確な指示、KB の原則化が挙動に与える影響が全く異なることが判明。未知の漏れを検出する真の「賢さ」を測るには、KB に記録されていない題材での評価が必須。

AIがコードを生成する時代に、従来のIDEは「タイピング速度」の最適化に留まっており、実際のボトルネックである「AIの出力を判断する速度」を支援していない。著者は、HTMLのその場レンダリングや仕様・差分の可視化により「判断を速くする」ために設計したダッシュボード型IDEを開発・運用している。