インターフェースの提案は、処理の権限を与えるのか

AIは画面の構成、表示する情報、用意する操作を提案できる。その提案の実装、データの正しさ、処理の権限には、それぞれ別の判断が必要だ。Muhitではこの境界をどう扱っているのか。

研究メモを見直したいとしよう。資料をまとめ、不足している点を示す表示をシステムに求める。

モデルは要約、資料のテーブル、いくつかの操作を提案する。画面には「メモを確認する」「修正を適用する」「公開する」といったボタンがあるかもしれない。

ここまでに行われたのは、作業環境の提案だ。しかしボタンが見えるようになると、別の問いが生まれる。どのレコードが変わるのか。誰が変更できるのか。利用者の選択をどう把握するのか。処理が終わったとき、何を根拠に完了と伝えるのか。

MuhitでAIによるインターフェース生成に取り組むうえで、こうした問いを画面の裏側で曖昧なままにしたくない。

提案には理解できる形が必要だ

モデルは利用者の依頼をもとに、どの情報を一緒に示すと意味があるかを提案できる。長い回答を節に分け、比較するレコードをテーブルに並べ、編集が必要な項目のフォームを記述することもできる。

これは、まだ見せ方が決まっていない内容でとくに役に立つ。必要が変われば、表示も変えられる。

MuhitのJSONインターフェースアダプターは、こうした提案を定義済みのコンポーネントへ変換する層として働く。モデルへの接続はアプリケーションが担う。アダプター自体に、独立して動くモデルや自律的な処理サービスは含まれていない。

受け取った定義は、まず検証される。コンポーネントの種類、必須項目、対応する値を確認する。有効な定義を、許可されたコンポーネントで画面に描画する。

こうしてモデルの提案は、アプリケーションがあらかじめ定めた表現の範囲に入る。定義に任意のコードや処理の権限を持たせることはできない。

ただし、この検証が何を示すのかは、正しく理解する必要がある。

見出しの形式が正しくても、その下の主張が正しいとは限らない。有効な行で構成されたテーブルでも、レコードが最新である証拠にはならない。定義に操作が含まれていても、その実行が許されているとは限らない。

有効なインターフェース定義だけでは、内容の正しさや処理の権限を判断できない。

研究メモの例なら、資料の出所、対象となる版、どの情報がモデルの解釈なのかを、アプリケーションが別途明確にする必要がある。整った画面で、これらの区別を代替してはいけない。

ボタンから実際の処理まで

Muhitでは、カードの操作から、コンポーネントと操作の識別子を含むイベントをアプリケーションへ渡せる。アプリケーションは、そのイベントを自身が認識する振る舞いに対応づける。

たとえば「メモを確認する」は、アプリケーションが指定したレコードの詳細を開く操作になるかもしれない。アダプターが操作名を読んで、自分でアドレスを作ったり、データを保存したり、公開を開始したりすることはない。

この境界には実際的な意味がある。モデルがボタンに「公開する」と書いても、それだけでアプリケーションに新しい公開機能が備わるわけではない。アプリケーションがその処理を認識し、対象のレコードを決め、必要な権限を確認しなければならない。

公開を行うアプリケーションなら、次のような経路を組み立てられる。利用者が変更案を確認し、アプリケーションが対象のレコードと範囲を示し、サーバーが権限とレコードの現在の状態を確認する。成功は、実際の処理の結果を受けてから伝える。

この流れは、Muhitが単独で提供する公開システムではない。Muhitのコンポーネントを使って構築できるアプリケーションの振る舞いの一例だ。

ここには、イベントと利用者の意図を区別する必要もある。コンポーネントから届くイベントだけでは、権限のある人間の指示だという証拠にならない。状態イベントの一部は、アプリケーションコードによる変更からも生じる。イベントハンドラーの存在は、本人確認や権限確認の代わりにならない。

だから、画面のボタンが見えることに権限を結びつけるだけでは不十分だ。処理を実行する層でも権限を評価しなければならない。

二つ目の文章では、ローカルでの確認と永続的な保存の違いを扱った。同じ原則がここにも当てはまる。画面が伝える結果は、実際に行われた処理の範囲を示すべきだ。

人の制御は理解から始まる

制御を確認ボタン一つに還元するのは簡単だ。しかし、何を承認するのか理解できなければ、ボタンがあるだけでは足りない。

研究メモの例では、「修正を適用する」を選ぶ前に変更案が見える必要がある。どの文が変わるのか。変更は資料に基づくのか、モデルの解釈なのか。現在の文章のどの版を使っているのか。

これらの情報が、判断の文脈をつくる。

人の制御を保つインターフェースには、提案を確認し、必要なら修正し、取りやめる経路が必要だ。すべての処理に同じ重さの確認を求めるのではなく、影響に応じた制御の形を考えたい。表示を絞るフィルターと、公開中の文章を変える操作では結果が異なる。

モデルが新しい提案を出すときも、この連続性を壊してはならない。入力欄を編集中に画面を再構築するなら、書いている内容がどうなるかをあらかじめ決めておく必要がある。

Muhitのアダプターは、無効な更新では現在の表示を維持する。有効な更新が成功すると表示を再構築し、以前のテーブルのフィルターや選択は自動では引き継がない。維持すべき利用者の状態があるなら、アプリケーションが別途管理しなければならない。

この技術的な細部は、人の制御に直接関わる。利用者は、自分の変更とモデルの新しい提案を区別でき、始めた作業に戻れる必要がある。

Muhitで築こうとしている境界はここにある。モデルが提案できる範囲を明確に定め、アプリケーションの責任と人の判断を見えるままにすることだ。

画面を生成できることは、大きな可能性をもたらす。その画面を安心して使うには、提案から実際の結果に至る経路が理解できなければならない。

利用者が**「これはシステムが提案した。この部分は自分で変えた。この処理を自分で選んだ。この結果は実際に起きた」**と言えるとき、インターフェースは制作の余地を開きながら、判断の跡を保つ。

---

資料：Muhitの JSONインターフェースの契約 とローカルな開発ソースの設計原則。研究メモと公開の流れは、責任の境界を説明するための例示的なシナリオである。

これまでのMuhitの文章: Muhit：インターフェースの一貫性は何から生まれるのか · Muhit：設計上の判断は画面でどう働くのか

Atlasの概念: 設計 · ソフトウェア · 文脈 · システム · 知能