全部、いちから作ればいい。

「動かしてから語れ」シリーズ #0（序章）

「今回の案件、n8nでワークフロー組みましょう」「Google AI Studioでモック作ったら爆速でした」「RAGですね！ナレッジベース構築しましょう」「Difyでオーケストレーション組めますよ」

案件ごとに新しいツールを持ってくる人がいる。テンション高く、目が輝いている。まるで銀の弾丸を見つけたかのように。

そのたびに思う。

1から作ればいいじゃないか。なんのためのエンジニアがいるんだ。

n8nはビジュアルワークフローツール。ノードを線で繋いで、処理の流れを組む。プログラミングなしで自動化できる、という触れ込み。

ノードを繋ぐUIを覚える時間で、シェルスクリプトが書ける。しかもシェルスクリプトは中身が全部読める。壊れたら直せる。n8nのノードが壊れたら、GUIをポチポチして原因を探る。どっちが速いかは明白だ。

ビジュアルワークフローは「コードが書けない人」のために存在する。書ける人間が使う理由がない。

Google AI Studioでモックを作る。「爆速でプロトタイプが完成！」と喜ぶ。そこまではいい。

問題はその先。そのモックをエンジニアに渡す。

バグが多すぎる。コードの品質が低すぎる。手直しに工数を取られすぎる。本来なら新機能を作る時間が、AI生成コードの尻拭いに消える。モックアップが負の遺産になる。渡さなかった方がマシだった、という結末。

Difyも同じ構造。オーケストレーションツールで処理を組む。見た目は動く。中身はブラックボックス。エッジケースで壊れたとき、誰が直すのか。結局エンジニアが中を開けて、ツールの仕様と格闘する。

プロンプトをちゃんとセクションごとに磨けばいい。オーケストレーションも、API直叩きで十分。中間層を挟むから複雑になる。

「RAGですね！」が合言葉のように飛び交っている。

Retrieval-Augmented Generation。外部知識を検索して、AIの回答精度を上げる仕組み。理屈はわかる。大量のドキュメントからAIが適切な情報を引っ張ってくる。賢い。

だがまず聞きたい。そのドキュメント、ちゃんと整理されているのか。

ゴミが散らかった部屋に高性能な検索エンジンを置いても、見つかるのはゴミだ。RAGを導入する前に、ファイル構造を設計しろ。ディレクトリを整理しろ。命名規則を決めろ。メタデータをつけろ。

構造化されたファイルに対して、プロンプトを丁寧に書く。それだけで大抵の「RAGで解決したかった問題」は消える。

検索の仕組みを足す前に、検索する対象を整えろ。

n8n、Google AI Studio、Dify、RAG。

全部、中間層。自分とコードの間に挟まるもの。

中間層は「自分で作れない人」のために存在する。コードが書けない人がノードを繋ぐ。プロンプトが書けない人がGUIで設定する。ファイル設計ができない人が検索エンジンに頼る。

作れる人間が中間層を使う理由はない。むしろ邪魔になる。中間層が吐いたゴミを、作れる人間が尻拭いする。これが今、現場で起きていること。

ここから5本、個別のツールを解剖する。

全部、自分で触った。全部、壊れるまで使い込んだ。だから書ける。

設計図は渡さない。壁の場所は教える。超え方は、自分で見つけろ。

それぞれのWe ship. We own.があっていい。