【ITニュース解説】FlowScript 0.1: A semantic language for describing applications before implementation

FlowScript 0.1は、アプリケーションが実際にどう動くのか、その「意味のモデル」を、まだプログラムを書き始める前に、人間が読みやすい形で記述するための新しい試みだ。ソフトウェアを開発する際、まず何を作るかを考えるが、現代のアプリケーションは非常に複雑で、ただのフローチャートではその全体像や振る舞いを表現しきれないという課題があった。画面の構造、ユーザーインターフェース、画面間の移動、ユーザー操作、データがどのように流れるか、状態の変化、エラー処理、そして異なるデバイスでの表示方法など、考慮すべき要素は多岐にわたる。FlowScriptは、これらの複雑な要素を、実装技術（例えば、どのプログラミング言語を使うか、ReactなどのUIフレームワークを使うか、どんなデータベースを使うかなど）に縛られずに表現できることを目指している。

このプロジェクトの中心となる考え方は、「アプリケーションが何であるか、そしてどのように振る舞うか」を、具体的にどう実装するかを決める前に記述するというものだ。つまり、後から実装方法が変わったとしても、FlowScriptで記述されたモデルは変わらず意味を持ち続けるべきだ、という考え方だ。これは、設計と実装を明確に分離することで、アプリケーションの全体像をより深く理解し、柔軟な開発を可能にすることを目指している。

FlowScriptは、アプリケーションの様々な側面を独立した概念として捉え、それぞれを明確に区別する。例えば、アプリケーションの「構造」と「ナビゲーション」は別物と考える。あるページが別のページを内包する階層構造は、ユーザーがそのページに直接移動できるかどうかとは異なる。FlowScriptでは、これらの関係を明示的に記述することで、曖昧さを排除する。同様に、「構造ツリー」（何が何を含んでいるか）、「ナビゲーショングラフ」（何から何へ移動できるか）、そして「状態グラフ」（アプリケーションの状態がどう変化するか）は、それぞれ異なる視点からアプリケーションを捉えるものであり、FlowScriptではこれらを別々のグラフとして扱う。これにより、それぞれの側面をより明確に、かつ厳密にモデル化できるようになる。

また、アプリケーションの論理的なモデルと、それがユーザーのデバイス上でどのように表示されるかという「プレゼンテーション」も厳しく区別される。例えば、同じ「詳細ページ」という論理的な要素であっても、小さな画面では単独で表示され、大きな画面では他の情報と並んで表示されるといった、いわゆるレスポンシブUIの挙動も、この分離によって、アプリケーションのモデル自体を変えることなく表現できるようになる。さらに、ユーザーがボタンを押すといった「アクション」と、システムがデータを保存するなどの「システム処理」、そしてその結果として起こる画面遷移である「ナビゲーション」も、それぞれ異なる意味を持つイベントとして区別する。これにより、アプリケーションの振る舞いをより理解しやすく、再利用もしやすくなる。条件が真か偽かを判断する「条件」と、オブジェクトやプロセスがどのような段階にあるかを示す「状態」も、複雑なモデルにおいて混同されがちな概念だが、FlowScriptではこれらも明確に区別し、それぞれを独立した要素として扱う。

FlowScriptの記述構文は意図的にシンプルに保たれており、「キーワード:値」という形式と、インデントによる階層表現が用いられる。これは、人間にとって読み書きしやすいようにするためだ。構文はシンプルだが、その背後にあるセマンティクス（意味論）は非常に厳密であることを目指している。将来的には、FlowScriptの記述が、参照の一貫性や、ネストの整合性、ターゲットの妥当性などを自動的に検証できるような仕組みも考慮されている。

FlowScriptは、既存のプログラミング言語（TypeScript、JavaScriptなど）や、HTML、CSS、バックエンドコード、データベーススキーマ、ビジュアルデザインツールなどを置き換えることを目的としていない。これらのツールはアプリケーションを「実装」するためのものであり、FlowScriptはそれらとは異なるレベルで、アプリケーションの「セマンティックな構造と振る舞い」を記述するものだ。

このプロジェクトの長期的な目標は、もしアプリケーションのセマンティックモデルを十分に厳密に表現できれば、その一つの記述から、階層図、ナビゲーショングラフ、状態図、レスポンシブなプレゼンテーションマップ、ドキュメント、テストケース、さらには実装の足場となるコードまで、様々な成果物を生成できるようになる可能性を探ることにある。FlowScript 0.1はまだそこまで到達していないが、基礎となるセマンティックモデルが有用であるかどうかの検証が、この目標達成の鍵となる。

このFlowScript 0.1が開発の初期段階で公開されたのは、最も難しい問題が構文ではなく、どの概念が本当に重要か、どれが重複しているか、どのような区別が必要かといった「セマンティックな問題」だからだ。これらの問いは、一人で考えるのが非常に難しいため、早期に公開し、広く意見や批判を募ることで、モデルをより強固なものにしようとしている。現在の段階で特に求められているフィードバックは、構文の変更提案ではなく、提供されているセマンティックな区別が理にかなっているか、概念は普遍的か、モデリングのレベルは適切か、重要な概念が欠けていないか、といったモデルの根本に関わるものだ。

プロジェクトは、「概念」から始まり、「セマンティックモデル」、「語彙」、「構文」と進み、最終的に「ツール」へと至る開発順序を意図的に採用している。これは、文法を早期に固定してしまうと、その背後にあるモデルが未熟なうちに、言語が正確であるかのように見えてしまうのを避けるためだ。FlowScript 0.1の目的は、このセマンティックモデルがどれだけ有効かを検証することにある。

このプロジェクトが最終的に問うているのは、FlowScriptのモデルを見るだけで、アプリケーションの実装を知らない人がそのアーキテクチャや振る舞いを理解できるか、という点だ。さらに強力なテストとして、同じアプリケーションの異なる二つの実装が、同じFlowScriptの記述で表現できるかという問いがある。もしこれらの問いに対する答えが最終的に「イエス」であれば、FlowScriptは単なるフローチャートよりもはるかに興味深い、そして価値あるものになるだろう。答えが「ノー」であれば、なぜそうなったのかを教えてくれるはずだ。