nokode - LLMが全部できるなら、なぜコードを書く必要があるのか？（Webアプリ実験）

 (github.com/samrolken)
8 ポイント 投稿者 GN⁺ 2025-11-02 | 2件のコメント | WhatsAppで共有
  • アプリケーションロジックが一切ないWebサーバーを構築し、LLMがすべてのリクエストを処理するようにした実験
    • サーバーは単にHTTPリクエストを受け取り、LLMに**「何をすべきか？」**と尋ね、残りはすべてLLMが実行
  • サーバーは database、webResponse、updateMemory の3つのツールだけを使ってCRUD機能を実行
  • LLMが SQLスキーマ設計、HTML・JSON生成、フィードバック反映 まで自力で行い、基本的な連絡先管理アプリを実装
  • 応答速度は 30〜60秒、コストは 従来のWebアプリ比で100〜1000倍 高く、UIの一貫性や記憶力の問題も存在
  • それでも コードなしで動く完全なCRUDアプリを実装できる可能性 を示し、コード自体が過渡的な概念かもしれないことを示している

背景

  • 「いつか私たちはコードを書く必要がなくなるだろう」 という空想的な発想（Shower Thought）から始まった
    • 未来にはLLMが リアルタイム入力を処理し、120fpsの動画を出力 し、アプリもコードもない純粋な意図ベースのコンピューティング が可能になるかもしれない
  • 現実ではまだ SFの領域 だが、週末の実験として 「今の技術でどこまで可能か」 を自分で試すことにした
  • 実験の 仮説 は、失敗を予想した状態から出発していた
    • 多くのAIが コード生成の方向（例: Claude Code、Cursor、Copilot など）に集中している中で、
      「コード生成を完全に省略したらどうなるか？」 という別の視点を検証するためにプロジェクトを作った
  • 結果として ルート、コントローラー、ビジネスロジックが一切ないHTTPサーバー を作り、すべてのリクエストについてLLMに 「何をすべきか？」 と尋ねる形で動作させた
  • 実験の目的は 「その未来が実際にどれほど遠いのか」 を証明すること

プロジェクト概要

  • nokode は、アプリケーションロジックのないWebサーバー を構築し、すべてのリクエストをLLMが処理する構成を試した実験
    • サーバーは単にHTTPリクエストを受け取り、LLMに 「何をすべきか？」 と尋ね、残りはすべてLLMが実行
  • 目的は コード生成なしでLLMが直接アプリケーションロジックを実行できるか を検証すること
  • 実験対象は 連絡先管理アプリ（contact manager） で、基本的なCRUD機能（登録、参照、更新、削除）を含む

システム構成

  • バックエンドはたった3つのツールで構成
    • database: SQLiteでSQLを実行し、LLMがスキーマを直接設計
    • webResponse: HTML、JavaScript、JSON など適切な形式で応答を生成
    • updateMemory: ユーザーフィードバックをMarkdownで保存し、次のリクエスト時に参照
  • 例として /contacts リクエスト時にはHTMLページ、/api/contacts リクエスト時にはJSONレスポンスを生成
  • 各ページには フィードバックウィジェット が含まれ、「ボタンを大きくして」、「ダークテーマに変えて」 のような要求を即座に反映

実験結果

  • 機能面では動作に成功
    • フォーム送信、データ保存、UI表示、APIレスポンスがすべて正常に動作
    • LLMは例示なしでも 適切なデータベーススキーマ、安全なSQL、REST風API、レスポンシブレイアウト、フォーム検証、エラー処理 を生成
  • 性能上の問題
    • 1リクエストあたり30〜60秒を要し、既存のWebアプリ（10〜100ms）と比べて 300〜6000倍遅い
    • 1リクエストあたり $0.01〜0.05 のコストが発生し、100〜1000倍高価
    • UIの色やレイアウトの不一致、以前の状態を記憶できないこと、誤ったSQLを生成すると即座にエラーになることなどの問題がある
    • 「⚡ THINK QUICKLY」 のようなプロンプト最適化の試みは、むしろ速度低下を招いた

結論と示唆

  • LLMには アプリケーションロジックを直接実行できる能力 がある
  • 問題は 速度、コスト、一貫性、信頼性 といった性能上の限界にある
  • しかし、これらの限界は 質的な問題というより量的改善の領域 であり、
    • 推論速度は毎年およそ10倍向上
    • コストは低下傾向
    • コンテキスト長の拡張で記憶力改善の可能性
    • エラー率も低下傾向
  • 結果として、「AIがコードを書く時代」 より 「AIが直接実行する時代」 のほうが近いかもしれない
  • 現在残っているのは、HTTP設定、ツール定義、DB接続などの インフラレベルのコード のみであり、
    長期的には 「意図と実行だけが存在するコンピューティング」 への移行可能性を示している

実行方法

  • npm install の後、.env ファイルにLLMプロバイダーとAPIキーを設定
  • npm start を実行後、http://localhost:3001 にアクセス（最初のリクエストは30〜60秒かかる）
  • prompt.md を修正してアプリの種類や機能を変更可能
    • /game、/dashboard、/api/stats などさまざまなパスを試せる
    • 「make this purple」、「add a search box」 などのフィードバック入力で即時反映
  • 1リクエストあたりのコストはモデルによって $0.001〜0.05 程度
  • MITライセンス で公開

関連記事

2件のコメント

 
aer0700 2025-11-05

結局のところ、コンピューティングがどこまで速く、どこまで安くなるかが問題でしょうね。
平均的なサーバーが今より10万倍速くなって、それでも運用コストや導入コストはそのままという未来なら、あれも正しいやり方なのだと思います。
コンピューティングが安くなるにつれて、機械語からCへ、Cの代わりにNode.jsやPythonへ移ってきたように、これからはLLMへ移っていくのかもしれません。
多くのことが変わるでしょうし、それなりに面白そうです。いろいろな機会も生まれるでしょう。
 
GN⁺ 2025-11-02
Hacker Newsの意見

  • 自分も似たようなことを考えていた

    1. もしコード生成が完全に自動化され、あらゆるGoogle検索がリアルタイムでカスタムページを作り出すようになれば、もはや人間がWebサイトを作る必要はなくなるのではないか？ その時点では「Web開発」はコーディングではなく、意図設計(intent-shaping) に近いものになる気がする
    2. また、チャットがユーザーインターフェースの理想形だという主張には同意しない。自然言語は柔軟だが遅く、曖昧で、認知負荷が大きい。おそらくLLMベースのシステムには、対話と構造化されたインタラクションを組み合わせた新しいUIモデルが必要になるだろう

  • ChatGPT 3.5が登場したときに、最初にこうしたことを考えた
    いつかAIがプログラムを完全に置き換えるかもしれないが、本当の核心は正しい抽象化(abstraction) を見つけることだ
    たとえばCVSからGitへの移行がマイクロサービス時代を切り開いたように、優れた抽象化には問題そのものを根本から変える力がある
    LLMがこうした抽象化を自力で発見するには、現実世界と長く相互作用しながら学習する必要がある

  • LLMが直接コードファイルを修正できるツールを追加すれば、応答速度と一貫性が大きく向上しそうだ
    コードが一種の記憶ストア(memory) として機能することになる
    LLMに直接HTTPリクエストを送るのはキャッシュミスに近く、コード更新をトリガーするフィードバック機構も維持できる

    • これは単純な実験で、まだボトルネックが多いことを示そうという意図だった
      最適化の余地は大きいが、現実的には依然として従来のコーディング方式のほうが効率的だと思う
    • こうした構造は、まるで種(seed) を植えるように、成長の方向と境界を定義することだ
    • 自分で作ってみるとよいと思う

  • 「非決定的(non-deterministic)な動作ができるなら、なぜわざわざ決定的である必要があるのか？」という問いのように聞こえる
    だが大半の人は、毎回違う動作をするWebアプリは望まないだろう

    • 実際には、人々が欲しいのは「Webアプリ」そのものではなく、問題解決(solution) だ
      決定論的なコードには複雑な問題を扱ううえで限界があり、人間のように柔軟なアプローチのほうが適しているかもしれない
    • 今のLLMは主にテキスト出力に制限されており、長期記憶もほとんどない
      しかし将来は、LLMがより豊かな出力と保存能力を持つようになるだろう
      たとえばLLMが直接リンクを生成し、それをクリックすると内部的に再クエリしたり、一時的なデータベースを管理したりする形で動作できる
    • 自分の意図は、非決定的な振る舞いが良いと言いたいのではなく、現在とポストコード(post-code) 時代のあいだにあるギャップを示したいということだ
    • 実際、今日のソフトウェアも完全に決定的ではない
      自動更新、A/Bテスト、UX変更などによって、ユーザー体験は絶えず変化している
    • temperatureを0にし、LLMが設定をローカルファイルに保存するようにすれば、決定的なアプリを作ることもできる

  • 興味深いことに、このアプローチは別のツールなしでもコンテキストウィンドウだけで動作する
    2025年7月にPOCを作ってみた

  • この実験は、「ボイラープレートコード」という概念がどう変わるのかをよく示している
    複数のインスタンスをサンドボックスで同時実行し、内部評価で最もよく機能した結果を返せば、一種のメタ強化学習(meta reinforcement learning) になる
    ただし、ユーザーの意図を決定的な出力へ翻訳するのは難しく、逆に従来型アプリは柔軟性に欠ける
    結局のところ、意図解釈(intent evaluation) をどう安定して実装するかが核心だ

    • ただし、内部評価方式にモデルが過学習するリスクがある
      良い評価メソッドを作ること自体、AIモデルを作るのと同じくらい複雑だ

  • 従来の方式でリクエストを処理するほうが、LLMを直接使うよりもコスト効率ははるかに高い
    おおよそ70億パラメータのモデルで10トークンを生成するのに、100 GFLOPs以上が必要だ
    電力の無駄が大きい

    • とはいえ、人間の労働にかかるエネルギーコストも計算に含めるべきではないかと思う
      エンタープライズITで働いていると、人間の非効率さも相当なものだ
    • 産業の進む方向は、常に最適化と一致するわけではない
      非効率ですらトレンドになるのが現実だ
    • それでも、LLMで素早くプロトタイプ(V1) を作り、プロダクト・マーケット・フィットを確認したうえで、従来型コードで最適化するというアプローチは有効だ

  • いっそLLMをポート443に載せて、「お前はHTTPSサーバーであり、アプリサーバーでもある」と指示すればいいのかもしれない ;)

  • そもそもWebアプリは必要なのだろうか？ ただ音声でコンピュータと会話すればいいのではないか？
    「去年の休暇で撮った写真を見せて、雲は消して、友だちに送って」
    「運動タイマーをセットして、ジャンピングジャックは外して」
    「デトロイトスタイルのテクノビートを作って」
    「今夜のデート相手を探して、黒髪が好み」
    こうやって、あらゆることを言葉だけで処理する世界を想像してみる

    • しかし、こうした自動化は人間の自律性(agency) を弱める可能性がある
      最終的には、これを受け入れる人と拒む人に人類が分かれていく気がする
      すでにアナログレコードの復活のような現象に、その兆しが見える
    • 音声インターフェースがすべてのコミュニケーションの答えというわけではない
      人間同士でもしばしばテキストが好まれる
    • 自分も今週、WebSpeechで音声入力を受け、org-modeとlogseqのファイルを読み書きする個人知識管理アプリを作ってみた
      ToDo、買い物、スケジュール管理までできて、完全に自分のニーズに合わせてカスタマイズされている
    • こうした未来はSFでたびたび描かれてきた
      複雑な作業は音声だけで十分表現できるが、単純な反復作業はUIのほうが効率的だ
      たとえば「ズボンを買って」と言ったとき、30件の結果から1つを選ぶには、結局は視覚的インターフェースが必要になる

  • 自分も似たようなPoCをGitHubに上げてある
    初期段階では遅い「デザインモデル」でアプリのテーマとDBスキーマを作り、その後は高速なモデルで応答を処理する
    PostRESTを使ってロジックをDBに入れてみたが、スキーマ生成の失敗や誤ったクエリ生成が頻発した
    CSSライブラリでUIの一貫性を保ち、前のページを記憶するようにした
    こうしたアプローチは、LLMが一度で完全なアプリを作れるかを評価するApp Benchとして活用できそうだ