1.1. アプリケーション操作の抽象化

利用者が違っても、操作する対象は共通する

Issueを閉じるという操作は、人間が画面から行っても、AIがToolを呼んでも、別のシステムがAPIを呼んでも、アプリケーション上ではIssueに対する操作である。利用者によって入力の仕方や結果の見せ方は変わるが、対象の意味まで変わるわけではない。

それでも、各接点では操作を異なる形で記述する。画面にはボタンや入力欄を設け、AIにはTool名と引数のSchemaを提示し、プログラムにはendpointやmethodを提供する。内部で同じ処理を呼んでいても、外部からは、それぞれの接点に合わせて対象と操作を理解する必要がある。

WIPの出発点は、この違いの下に、アプリケーションを操作するための共通モデルを置けないかという問いである。AIのためだけにToolを整理したいのではない。人間もAIもシステムも利用できる、操作インタフェースそのものを抽象化したい。

アプリケーションを使う主体には、少なくとも、操作する対象、その対象が何を表すか、利用可能な操作、操作に必要な入力、返される結果を知る手段が必要になる。これらを共通の契約として公開できれば、Clientは用途ごとの接点を、その契約に基づいて構成できる。

人間には対象の一覧や操作フォームとして、AIには対象の説明とTool呼び出しとして、プログラムには型付きのAPIとして提示できる。同じモデルを使うことは、全員に同じ表示や呼び出し構文を使わせることではない。

また、共通のモデルからUIやToolを作れることと、用途に最適なUIや判断手順まで自動的に得られることは別である。画面の構成、操作の選び方、結果の解釈には、それぞれのClientやアプリケーションに固有の設計が残る。共有したいのは、それらの設計が参照する対象と操作の契約である。

操作を呼び出す形式が揃っていても、利用者が呼出先と引数をすでに知っていることを前提にすると、未知のアプリケーションを扱う手順は共通にならない。何を対象にできるか、必要な機能がどこにあるか、どの操作が使えるかを、別の文書や個別の組み込み知識から得る必要がある。

プログラムが既知のAPIを呼ぶ場合には、その前提で足りることもある。一方、人間やAIが環境を調べながら操作する場合や、システムが公開された機能を動的に扱う場合には、対象と操作を発見する手段も必要になる。

そのためWIPでは、実行だけでなく、発見と観測も操作モデルに含める。どの対象へ作用するかを決め、その対象の公開情報を確認してから操作する。対象を知ることと操作を呼ぶことを、別々の接続方式へ分散させずに扱いたい。

人間・AI・システムが同じモデルを使っても、同じ対象や操作をすべての主体へ公開する必要はない。公開する範囲も、実行を認める条件も、主体によって異なり得る。

Issueを見つけられたことだけでは、そのIssueを閉じる権限があるとは限らない。共通インタフェースは、こうした区別をなくすものではない。公開された対象と操作を同じ形式で理解できるようにしながら、可視性と実行時の認可はHostが判断する。