Nagashi-Somen Architecture（流しそうめんアーキテクチャ）

2026年4月1日
https://lab.ai-makouro.com/word_registry/view.php?id=83

― スパゲティコードの対極にある、日本発の流路設計思想 ―

「スパゲティコード」という言葉は昔からある。
処理が絡まり、依存が増え、どこから来てどこへ流れているのか分からなくなった構造を揶揄する言葉だ。

だが、もし最初から「絡まらない流れ」を前提に設計したらどうなるか。

その発想から生まれたのが、Nagashi-Somen Architecture である。

これは、流しそうめんの構造をメタファーとして用いた設計思想だ。
処理を個別に積み上げていくのではなく、データが流れる流路そのものを設計し、その通過過程で取得・分岐・処理・通過を自然発生させることを基本とする。

スパゲティが「混ざること」で成立する構造なら、流しそうめんは「流れること」で成立する構造である。
この違いは単なる食文化の違いではない。
ソフトウェア設計における、密結合と疎結合、固定処理と流路設計の差そのものでもある。

■ Nagashi-Somen Architectureとは何か

ここで重要なのは、主役が「個別の処理」ではなく「流れ」そのものに置かれている点だ。

従来の設計では、関数やクラス、モジュールごとに責務を分け、処理を積み上げていく発想が主流だった。
それに対してNagashi-Somen Architectureでは、まず「どこから流れ、どこで拾い、どこを通過し、どこへ抜けるか」を決める。

処理は固定された命令の塊ではなく、
流れてきたものに対して、途中でどう振る舞うかという形で配置される。

つまりこれは、処理を書く思想というより、
流れを設計する思想である。

■ なぜ「流しそうめん」なのか

この構想の核は、比喩の面白さではなく、比喩と構造の一致率の高さにある。

流しそうめんには、すでに以下のような構造が内包されている。

これらは、現代のシステム設計においても極めて相性がいい。

たとえば、ミドルウェア、イベントフック、フィルタ処理、ルーティング、ストリーム処理、データパイプラインなどは、それぞれ個別には既存概念として存在している。
しかしNagashi-Somen Architectureは、それらをバラバラの要素としてではなく、一つの流路思想として統合的に捉える。

つまりこれは、既存技術の焼き直しではない。
既存の点を、流しそうめんという一本の流れで結び直したものだ。

■ スパゲティコードとの対比

スパゲティコードは、処理が絡まり、混ざり、分離が難しくなった状態を指す。
関数や条件分岐が増殖し、依存関係が複雑化し、修正するたびに別の場所へ影響が飛ぶ。

パスタはソースと混ざって完成する料理である。
ミートソースも、ジェノベーゼも、カルボナーラも、混ぜることを前提に成立している。
これは料理としては美しいが、構造としては「一体化」を前提にしている。

一方で、流しそうめんは違う。

そうめんは流れ、つゆは分離され、必要な地点で取得される。
そして取られなかったものは、そのまま先へ進む。
この構造には、混ざることを前提としない成立性がある。

ここに、スパゲティコードとNagashi-Somen Architectureの決定的な差がある。

■ つゆが本体である

Nagashi-Somen Architectureを理解するうえで、もう一つ重要なのが「つゆ」の存在だ。

この構造では、麺そのものが本体ではない。
本体はむしろ、つゆ＝ロジック側にある。

そうめん、うどん、蕎麦、冷や麦。
流す麺の種類が変わっても、つゆが成立していれば全体は成立する。
つまり、データ形式が変わっても、処理ルールが整っていれば流路全体は破綻しない。

この発想は、そのままシステム設計にも置き換えられる。

ここでの本質は、麺を固定しないことだ。
Nagashi-Somen Architectureは、素麺しか流してはならないという狭い構想ではない。
美味く流せるなら、うどんでも蕎麦でもいい。

つまりこれは、特定データ専用の閉じた設計ではなく、
ロジックと流路の力で複数の入力を受け流せる抽象構造なのである。

■ 後付け拡張に強い理由

パスタソースは完成度を上げても、基本的には「混ぜて完成する構造」から抜け出せない。
一方、日本の麺つゆ文化は少し違う。

つゆはベースとして成立しつつ、
追いガツオ、昆布、薬味、七味、生姜、ネギなどで後から調整できる。
この「後付けで味を育てる」思想は、ソフトウェア設計にもそのまま響く。

Nagashi-Somen Architectureでは、
後からフックポイントを追加したり、特定の流路だけを分岐させたり、通過条件を追加したりできる。
しかも全体を壊さず、既存構造に寄生するように差し込める。

これは、拡張のたびに全体を書き換える構造ではなく、流れを崩さずに味を足していく構造だ。

そのため、変更に強い。
そして、設計が育つ。

■ 取り逃しても成立するという思想

Nagashi-Somen Architectureには、一般的な業務システム設計とは少し違う、独自の思想がある。

それが、「取り逃しても成立する」という考え方だ。

流しそうめんでは、すべての麺を必ず回収しなければならないわけではない。
途中で取れるものを取り、取れなかったものは流れていく。
この非強制性が、システム設計においては「必要な地点で必要な処理だけを行う」という柔軟性につながる。

もちろん、絶対に回収が必要な処理もある。
だがすべてをその前提で組むと、設計はすぐに重くなる。
Nagashi-Somen Architectureは、どこを必須回収地点にし、どこを通過許容にするかを流路設計の中で定義する。

この発想によって、構造は軽くなり、柔軟になる。
そして「全部を同じ熱量で握りつぶす設計」から抜け出せる。

■ 既存技術との違い

この思想は、データパイプライン、イベント駆動、ミドルウェア、ストリーム処理、関数型パイプラインなどと部分的に似ている。
しかし、どれとも完全には一致しない。

理由は明快だ。
既存概念の多くは「技術要素」の説明に留まっており、
流れそのものを文化的・構造的メタファーとして統合していないからである。

Nagashi-Somen Architectureは、
単なる技術分類ではなく、設計者の頭の中で流路を組み立てるための視点を提供する。

これはコードの書き方ではない。
設計の捉え方そのものの話だ。

■ 日本発であることの意味

この構想は、偶然日本文化を借りただけのものではない。
むしろ日本的な食文化と構造感覚が、そのまま設計思想へ転写されたものに近い。

パスタ文化が混合と完成を重んじるなら、
麺つゆ文化は分離と調整を許容する。
そして流しそうめんは、そこに「流路」という概念を加える。

日本には、分けて整える、後から加減する、取りすぎない、流れを読む、といった感覚が昔からある。
Nagashi-Somen Architectureは、そうした感覚がソフトウェア設計にまで滲み出た結果とも言える。

それゆえにこれは、単なる和風ネーミングではない。
メイドインジャパンの設計思想として意味を持つ。

■ 結び

Spaghetti Codeは、混ざりすぎた末の事故である。
Nagashi-Somen Architectureは、最初から絡まらないように流れを設計する思想である。

主役はコードの塊ではない。
主役は流れだ。

何を流し、どこで拾い、どこを通し、どこで変化させるか。
その全体を見渡しながら構造を組むとき、設計は「書く」ものから「流す」ものへ変わる。