安全網を半分しか張らず、完成だと思っている

今のAIコードパイプラインの実態を正直に見てみよう。

Cursor や Claude Code でコードを生成する。TypeScript の strict モードが型の不一致を捕捉するから、tsc --noEmit を実行する。ESLint も実行する。プルリクエストでセミコロンの議論をしたい人はいないからだ。dependency-cruiser も実行しているかもしれない。循環インポートは恥ずかしいことだから。テストは通る。出荷する。

そして、それが deterministic スタックだと思っている。

違う。それは型とスタイルのスタックに過ぎない。無効な状態を防ぎ、インポートの境界を強制できたのは確かに有益だ。だが、LLM が180行の関数を生成したこと——そのサイクロマティック複雑度がグラフ理論家を泣かせるほどのものだったこと——については、まったく何もしていない。3つの異なる module が、わずかに異なる変数名で同じヘルパーをコピーしていたことも見抜けなかった。エラー処理が、Promise の連鎖の底に、怠惰なバウンサーのように座っているたった一つの catch (e) { console.log(e) } であることにも気づいていない。

コードはコンパイルする。設計はきれいだ。それでもコードは客観的に最悪だ。

これが空白地帯だ。そしてこれは重大な問題だ。なぜなら、AI 生成コードはこの種のゴミを生み出す特別な才能を持っているからだ。構造的には正しい。設計的には準拠している。しかし内部から静かに腐っている。

欠けているレイヤーの正体

建物が構造技師の検査に合格することと、建物に住み心地が良いことの違いを考えてみよう。構造検査は建物が倒れないかを確認する。シャワーの水がキッチンのシンクに流れ込まないかまでは確認しない。どちらも重要だ。だが仕事の内容は違う。

既存の deterministic スタックは構造技師のようなものだ。以下を確認している：

  • 型: この値はこの形で存在しうるのか？
  • Lint: 構文は基本的な衛生基準に従っているか？
  • 設計ルール: インポートは境界を守っているか？
  • テスト: 正常系はクラッシュせずに実行されるか？

一方、以下は確認していない：

  • 複雑性: この関数の分岐が多すぎて、人間が正しく理解できないのではないか？
  • 重複: LLM が4カ所に、わずかな違いだけで同じロジックを生成したのではないか？
  • 命名: data は意味のある変数名か、それともプログラミングにおける肩をすくめる行為に等しいか？
  • エラー処理: エラーは実際に処理されているか、それとも捕捉されただけで無視されているか？
  • 構造: ファイルの構成は合理的か、それともゴミ捨て場になっているか？
  • コメント: 複雑な部分は説明されているか、それとも次の開発者が降霊術を必要とする状態か？
  • サイズ: このファイルが400行なのは必要だからか、それとも誰もモデルに止めるよう指示しなかったからか？

これらは審美上の好みではない。複雑性は欠陥密度と相関する。重複は、将来の変更が不整合になることを保証する。悪い命名は、あらゆる後続の変更において認知負荷を増大させる。不十分なエラー処理は、診断痕跡のない本番障害を意味する。

この点における研究は明確だ。私たち自身の多次元分析では、階層的な信頼性設計は、各レイヤーが前のレイヤーが見落とした欠陥を捕捉するときにのみ機能することが分かった。Layer 1 が型チェックで、Layer 2 がテストなのに、誰もコードが保守性の惨事になっていないか確認していなければ、スタックに穴が空いていることになる。そして AI 生成コードは、その穴を通り抜けるのを好む。なぜなら、モデルは見かけがもっともらしい実装を生成するのが得意で、それが実際には付き合うのが悪夢のようなものになりがちだからだ。

無礼な名前を持つツールの登場

fuck-u-code というツールがある——そう、本当にそれがコマンドだ——そしてこれは、パイプライン内の他のどのツールもやっていないことを正確に一つやってくれる。14の言語を横断して、deterministic な AST ベースのコード品質解析を実行し、実際の問題と相関する指標を使って、あなたのコードがどれだけ悪いかを正確に教えてくれる。

以下が確認対象だ：

  • 複雑性: サイクロマティック複雑度と認知的複雑度のスコア。関数に17の分岐があれば、フラグを立てる。
  • サイズ: ファイルおよび関数の行数。250行の関数を生成した LLM も、型が正しいからといって見逃されない。
  • コメント: コメント密度と品質。コメントが美徳だからではない。説明のない複雑なロジックは保守の罠になるからだ。
  • エラー処理: エラーが捕捉されたか、再スローされたか、ログ記録されたか、黙って飲み込まれたか。
  • 命名: 変数および関数の名前の品質。data、temp、handler、process は合格しない。
  • 重複: ファイル間で繰り返されるコードブロック。LLM のお気に入りの手法：検索と置換付きのコピー＆ペースト。
  • 構造: ファイル構成と module の凝集性。

全体スコアを0から100で出力する。高い方が良い。また、ファイルごとの「shit-gas index」も出力する——高い方が悪い——ので、どのファイルが最初に注意を必要とするかが正確に分かる。解析は tree-sitter AST パースによって完全にオフラインで実行される。コードがあなたのマシンを離れることは決してない。ほとんどのプロジェクトで1秒未満だ。

そして、まだ使っていなかったことに腹を立てるべきポイントがここだ：費用はまさに0ドル。

ツールが体現する哲学

fuck-u-code を興味深くするのは、確認対象だけではない。内部的な設計の仕方——このツール自体が、属しているパイプラインの完璧な縮図になっていること——だ。

このツールには2つのコマンドがある：

fuck-u-code analyze .          # Deterministic AST analysis. Offline. Fast. Free.
fuck-u-code ai-review . -m gpt-4o   # AI review of the worst-scoring files. API call. Costs tokens.

順序に注目しよう。デフォルトにも注目しよう。deterministic 解析は常に最初に実行される。API キーを必要とせず、お金がかからず、実行間で変化しないからだ。AI レビューはオプションの第2ステップで、最悪の上位Nファイルだけを見る。

これが、あなたのパイプラインが持つべき正確な設計だ。

すべてのプルリクエストを Greptile や Claude Code に送って、完全な意味論的レビューをしてもらう必要はない。それにはお金がかかり、時間がかかり、——以前の記事で確立したように——連続した実行で同じ問題を指摘するかどうか分からない確率的な出力を生み出す。まず deterministic ゲートを実行する。ミリ秒単位で、完全に再現性を持って、構造的な惨事を無料で除外する。その上で、そしてその時に限って、生存者を高価な AI レビューに送る。deterministic ツールではできない意味論的、設計的、動作的分析のために。

fuck-u-code は文字通り、これを内部的に実装している。analyze コマンドが Layer 1 の品質フィルタだ。ai-review コマンドが Layer 2 の意味論的深掘りだ。このツールは、それが可能にする原則の実演なのだ。

経済的な議論はほぼ侮辱的だ

しばらく金の話をしよう。なぜなら、ここが業界の現状が本当に腹立たしくなる部分だからだ。

AI コードレビュープラットフォームは、プルリクエストごと、あるいはレビューしたコード行ごとに課金する。費用は莫大ではない——プルリクエストあたり1〜2ドル程度かもしれない——だがゼロではなく、チームの速度に応じてスケールする。AI でコードを生成しているなら、速度は以前より高くなっている。つまりレビュー費用も以前より高くなっているということだ。

一方、fuck-u-code は14の言語を横断して codebase 全体を1秒未満で解析し、まさに無料で提供する。本当に問題のある上位20%のファイルにフラグを立てる。CI が利用できる JSON または Markdown レポートを生成する。平均スコアが設定した閾値を下回れば、ビルドを失敗させる。

deterministic 品質ゲートを先に通さずに、すべてのプルリクエストで AI レビューを実行しているなら、関数が複雑すぎることを発見するために API トークンのお金を支払っていることになる。それは、構造技師を雇って家が汚いと言ってもらうようなものだ。技師はその仕事に適任かもしれないが、あなたは彼らの時間とあなたの金を無駄にしている。

経済的に合理的なパイプラインは以下だ：

  1. AI がコードを生成する
  2. 型チェック、lint、設計ルール（既存のスタック）
  3. fuck-u-code analyze（欠けていた品質ゲート——$0、1秒未満）
  4. AI レビュー（Greptile など——だがステップ3を生き残ったファイルだけに、あるいはステップ3が興味深いパターンにフラグを立てた時だけ）

これは理論ではない。算数だ。deterministic ゲートは、deterministic ツールが設計された問題のクラスを捕捉する。AI レビューは、意味論的理解を必要とする問題のクラスを捕捉する。各ツールは得意なことをする。誰も構造的衛生のためにトークンを無駄にしない。

MCP 連携: ワークフローのために作られ、後付けではない

AI 支援開発を本気でやるなら、もう一つ重要な詳細がある。

fuck-u-code は MCP サーバーを同梱している。Claude Code、Cursor、その他の MCP 対応ツールを使っていれば、エージェントから直接 fuck-u-code analyze を呼び出せる。エージェントは AST パースやサイクロマティック複雑度を知る必要はない。ツールを呼び出す。ツールが構造化レポートを返す。エージェントがそれに基づいて行動する。

これが重要なのは、フィードバックループを閉じるからだ。コードを生成したのと同じ AI が、今やそのコードの品質についての deterministic フィードバックを、理解して行動できる形式で受け取れる。エージェントは src/auth/login.ts の shit-gas index が100点中87点であることを把握し、人間がそのプルリクエストを見る前に refactor することを決定できる。

以前、CI が仕様駆動開発を現実のものとする enforcement layer であることを書いた。MCP 連携は、fuck-u-code が単なる CI ゲートにとどまらないことを意味する。生成パイプラインがリアルタイムで参照できるエージェントがアクセス可能な品質オラクルなのだ。

実際に導入するとどうなるか

移行計画は必要ない。5分だけ必要だ。

npm install -g eff-u-code
fuck-u-code analyze .              # See your current scores
fuck-u-code config init            # Generate .fuckucoderc.json

閾値を設定する。最低全体スコアを選ぶ。個別ファイルごとの最大 shit-gas index を選ぶ。pre-commit hook に追加する：

# .husky/pre-commit
fuck-u-code analyze . --format json --output quality-report.json

あるいは CI に追加する：

# .github/workflows/quality.yml
- name: Code Quality Gate
  run: |
    npm install -g eff-u-code
    fuck-u-code analyze . --format markdown -o quality.md
    # Parse the JSON and fail if overall score < threshold

重みは設定可能だ。チームがコメントより複雑性を重視するなら、.fuckucoderc.json で指標の重みを調整する。テストファイルを除外したいなら --exclude を使う。デフォルトの10個ではなく、最悪の上位20ファイルを見たいなら -t 20 を使う。

そして、構造的な惨事を除外したら、興味深いファイルを AI レビューに送る：

fuck-u-code ai-review . -m gpt-4o -t 5   # Review only the 5 worst files

これがパイプラインだ。生成する。型チェックする。品質ゲートを通す。生存者を AI レビューする。出荷する。

正直な結論

fuck-u-code が codebase のあらゆる問題を解決するというふりはしない。レースコンディションは捕捉できない。認証ロジックに巧妙なタイミング攻撃があることを教えてくれない。property-based testing や mutation testing や形式検証や、以前の記事で話した他のどのレイヤーも置き換えない。

これがやってくれるのは、誰も今捕捉していない、退屈で予測可能で高価な問題を捉えることだ。AI 生成の API ハンドラーが300行もありエラー処理がないことを教えてくれる。3つの異なるサービスが同じバリデーションロジックをコピーしたことを教えてくれる。変数の半分が data や result という名前で、それを恥じるべきだと教えてくれる。

これらは限定的なケースではない。品質フィードバックループのない高速コード生成パイプラインのデフォルト出力だ。LLM は疲れないが、恥ずかしさも感じない。良いコードを生成するときと同じ自信で悪いコードも生成し、あなたの現在の deterministic スタックはそれを通してしまう。なぜなら、そのスタックは品質を確認するよう設計されていない。正当性を確認するよう設計されたのだ。

正当性と品質は別物だ。両方が必要だ。

fuck-u-code はすべての答えではない。特定の問いへの答えだ。「AI 生成の構造的ゴミをコードレビューに到達させるのを止める、最も安価で、最も高速で、最も deterministic な方法は何か？」

答えはこうだ。AST をパースし、指標を採点し、ビルドを失敗させ、モデルに再試行させる。

費用はかからない。1秒未満で完了する。そして、おそらく気づいていなかった安全スタックの穴を塞ぐ。