開発を why と action に分解する：判断エンジンで Runtime を作り直すという構想

今日イベントに参加して、すぐに書き留めておきたくなるインスピレーションを得た。

2026 年、jev という新しいエンジンが出た。現場の説明では、それは「判断エンジン」に属するものだという。もし「判断」という仕事をエンジンに任せられるなら、それを使って IT 開発のプロセスを再編成し、再設計できないだろうか。以下は、この思いつきに沿って、一日の議論を一本の筋道に整理したものだ。

開発は二つのことに抽象化できる

まず開発という営みを徹底的に抽象化してみる。僕の見方では、それは一つの動作——コンピュータ上で走る action にすぎない。では、なぜ開発するのか。why、つまり reason があるからだ。この action はなぜ存在するのか。

この二つを並べると、そのまま key-value のペアになる。why が key で、action が value だ。つまり「なぜ」のあとに「どの action」を実行するのか。徹底的に削ぎ落とすと、開発はこの二つだけになるのかもしれない。

判断エンジンに「今、何をすべきか」を決めさせる

判断エンジンがあるなら、新しい形を大胆に構想できる。コンピュータ、あるいは IT ハードウェアが、まず now——今どんな状態かを判断する。それは抽象的に推論するのではなく、input を受け取り、吸収する。つまり今の状態だ。そしてその状態を jev の判断モデルに渡し、あらかじめ登録しておいた key-value、つまり why-action のデータベースを引く。最後に二つの出力を得る。

1. 今の now という状況で、どの why-action を優先して実行すべきか。
2. それらの why-action をどの順番で実行すべきか。

あとはこれらの why-action を自動で実行させる。ここまでで「状態 → 判断 → 決定 → 実行」のループが形になる。

ループを閉じる：reaction で次の Y を発火させる

今日 Syama、Eva と議論したとき、Syama がとても良いアイデアをくれた。このループに欠けていた環をちょうど埋めてくれるものだ。jev に登録した Y で「どの action をすべきか」を決めたあと、その action を終えると何らかの feedback が引き起こされる。

彼が挙げたのはゲームの例だ。小さな兵士に戦わせたら、相手の大砲で HP を削り切られてしまう。この兵士の action 後の状態、たとえば悲しそうに一声鳴く——これが reaction だ。この「消耗されたとき、インタラクションされたときの状態」も action として登録し、別の Y を発火させる。そうすればループが自動で回り始めるではないか。これは今日得た良い筋道だ。

action には三つの形態があり、実行環境はまだ開かれた問い

次に答えるべきは、action は結局どんな形で存在し、どこで実行されるのか、という点だ。

現時点では action をこう定義できる。

• そのまま code、つまりコードやプログラム。
• あるいは skill として定義する。
• あるいは prompt そのもの。

本当に新しい runtime として実装するなら、実行環境の層をもう少し詰める必要がある。action は code を直接実行するのか。action が skill なら、harness engineering の環境を与えて、harness engineering の操作をさせ、その skill を実行し、その program を走らせるのか。action が prompt なら、それも動的に何かを生成し、動作になり、最終的にプログラム化されたフローになるのか。

now はどこから来るか：browser use のように画面を見張る

フロント側の「now の判断」にも具体的な構想がある。コンピュータを例にすれば、browser use のようなものを作り、あなたのディスプレイを監視して、繰り返し現在の状態を判断し続けられないか。それができれば、新しいタイプの runtime を構築できたことになるのではないか。

人に戻る：interview という入口が必要だ

runtime ができたら、さらに深く考えると、人間社会と結びつけることになる。

人にとって、何かに向き合うとき、why——なぜこれをやるのかを考えなければならない。どんな action ができるかも考えなければならない。さらにもう一度頭を働かせて、この action と why をどうつなげるかを考えなければならない。これらは今のところ、すべて人が自分で考えている。

そして人によって違う。こうしたことを考えるのが得意な人もいれば、多くの人にとっては、この行為自体がとても難しい。だから、runtime をできるだけ早く実際に使えるようにするには、まず人の問題を解決しなければならない。この人を interview する interface を提供し、その interview アプリないしシステムを通じて、その人にとって役立つ key-value、つまりその人自身の why-action データベースを生成してあげる。それをこの runtime 上で走らせればいいではないか。

この部分には哲学的な考え方も派生する。二つの人性だ。

• human like to：人が喜んでやることは、interview を受け入れ、自分のこうしたものについて話すこと。
• human want：人が手に入れたい結果は、自分のために事を成してくれる一式の仕組み。

いわゆる interview システム、あるいは資格変換システムがやることは、その人の why と action の間の関連性——この graph——を再構築することだ。それは中間に位置するシステムだ。

範囲を絞る：まず「仕事探しを手伝う」小さな実例を作る

こうした考えを踏まえると、いきなり大きなシステムを作るのは難しい。だから、今週と来週のテーマは範囲を絞って、小さな実例——仕事探しを手伝うもの——にできないかと思っている。

先ほどの方法で、三つのステップに分ける。

第一ステップ、interview の小さなアプリ。 その機能は、一つは人に話させること、もう一つは人を導いて話させること。自分に何ができるか、何を望むか、なぜそう判断するのか、といった情報を、できるだけ多く引き出し、話させる。話したあと、interview system がバックグラウンドで処理し、最終的な成果物はあの key-value の表、つまり why-action 表になる。これが interview system が最終的に行き着く一点だ。

第二ステップ、action をソフトウェアと結びつける。 action 自体はソフトウェアと関連づけられる動作なので、service type を与えられる。type は基礎的な software の実行、あるいは command line interface の実行、つまりそのままプログラムの実行にできる。あるいは、やりたい action を skill としてカプセル化し、たとえば harness engineering の CLI で走らせることもできる。prompt として包むこともできる。これらの action を登録し、対応する Y も登録する。

第三ステップ、あの全く新しい Runtime を起動する。 runtime の起動時には初期 action が必要だ。たとえば「仕事を見つけたい」。そして why-action のループを回す。たとえば、どれくらいの時間か放置して循環させる。あるいは先ほどの設計を使う。action のあとに、action 実行後の状態を検証する判断——reaction——を action に付ける。その reaction を判断し、reaction を新しい入力として browser use に投げ戻し、jev に Y を判断させ、action を判断させる。

最後に、これが本当にその人にとって、心から望む、自分に合った、やりたい仕事を見つける手助けになるかを見てみたい。試してみる価値はある。