研究者がLLM (Large Language Model)との対話を通じて、LEAPS-Softwareによるタンパク質設計のサイクルを回せるインターフェースとして設計した。私たちは、このインターフェースを**「対話型」と呼ぶ。対話型の狙いは、専門性の高い設定を事前の知識なしに、自然言語で要件を述べるだけで、LEAPS-Softwareの実験を安全に立ち上げられる点にある。言い換えれば、LLMを人が入力する「自然文」からシステムが理解する「制御文」に変換するオーケストレーター**として用い、研究者の操作にかかる負担を最小化する設計思想である。
対話の各ターンは以下の通りである
研究者は、データセットのCSVやTSVでLLMに提出する。LLMは、これをバリデーションし、予期した形式になっているかを確認する。
研究者は、目標とする値を自然言語で、LLMに提出する。LLMは、これをバリデーションし、予期した形式になっているかを確認する。
研究者は、結果を確認して、LLMと相談する。これにより、適切なパラメータの設定をフィードバックできる。
これターンをLLMで制御することで柔軟な入力を提供し、学習コストなしにアプリケーションの利用が可能にすることを目指した。最後に、対話型は柔軟性を高める反面、自由度が高いがゆえの設定の散逸が起こりやすい。そこで私たちは、後述するTool Callingという機能を採用した。
ここでは、私たちがどのように計画したかを示す。
バックエンドは、「同じ入力は同じ結果に到達する（再現性）」「何が起きたか後から説明できる（監査性）」「失敗しても安全に戻せる（可逆性）」という三つの前提を置いた。自然文の意図と選択すべき関数のペアをスキーマとしてJSON Schemaで定義し、コードより先にAPIを定義して、動作を検証した。
フロントエンドは、研究者が画面遷移なしに入力 から実行まで到達できることを中核に置いた。最初にユーザージャーニーを文章で起こし、会話と結果が意図した通りに行えるかどうかを検証した。プロトタイプは、バックエンドで適切な制御が可能になることを確認してから開発することとした。
ここでは、私たちがどのように設計したかを示す。
バックエンドは、モダンな技術を重視し、Neonをデータベースに、UploadThingをストレージとして採用した。ファイルの保存をストレージにし、ファイルの管理にデータベースにすることで、分責の原則に従った。
本システムの要であるLLMのTool Callingについて説明する。研究者の自然文をLLM がその意図を解析し、最適な関数を呼び出せる機能である。例えば、ユーザーが結果に不満が場合を考えよう。ユーザーは、改善を図るために情報が必要となる。LLMに原因を特定したいという意図を持った質問をすると、原因の特定を行う関数を呼び出す。これにより、研究者は学習コストなしで柔軟に指示できる一方、裏側では決定的な構成に収束する。
フロントエンドは、モダンな技術を重視し、Next.jsをフレームワークに、shadcnをUIライブラリとして採用した。フェッチングライブラリのSWRを用いて、楽観的更新と差分レンダリングを実現し、応答速度の向上に努めた。
研究のフローを途切れさせないことを目的にUIを設計した。対話型は、自然文で要求を表現できるため学習コストが低くなる。また、LLMを用いることで、連続する研究における文脈の理解が得られる。この利点を活かすため、チャットベースのUIを実装した。
ここでは、私たちがどのように検証したかを示す。
バックエンドでは、実際の研究を想定したシナリオ駆動の検証を中心に、意図が曖昧な指示を含むケースを用意した。Tool Callingは、分岐を網羅するようにテストした。再現性については、同じ指示のもとで、同じ結果が得られるかで確認した。監査性については、なぜその関数を呼び出したかという意図を尋ね、指示の意図と一致するかで確認した。可逆性については、ミスが発生しても正しくフォールバックされるかを確認した。
フロントエンドは、結局のところ実際に使ってもらうことを中心に据えた。私たちは初期のモック段階から、本番を想定した利用を行った。また、観察では手戻りがどの瞬間に生じるかだけを丹念に記録した。
ここでは、私たちがどのように改善したかを示す。
バックエンドでは、Tool Callingの検証をもとに、入力と出力の制御を行なった。しかし、実際には、すべてのパターンを網羅することはできず、組合せの爆発を招き、すべての道筋を網羅的に潰すのは現実的ではないことが明らかになった。加えて、操作性の向上は目的ドリフトを誘発しやすく、ユーザーの行動が単なるLLMとの会話ツールになり得ると考えた。
フロントエンドでは、フィードバックをもとに、UI / UX の改善を行った。しかし、実際には、ユーザーが主導となる対話では「最初の一歩」が見えにくく、どこから始めればよいか分からなくなった。これは、対話型の限界を示しており、迷いの生じないUI / UXの重要性が実感された。
研究者が段階的なフォームを通じて、LEAPS-Softwareによるタンパク質設計サイクルを進められるよう、「考えさせないUI」を軸に「迷わない導線」を提供するインターフェースとして設計した。私たちは、このインターフェースを「フォーム型」と呼ぶ。version1の対話型の知見から、初動で迷いが生じやすいことが分かったため、フォーム型では入力すべき項目を構造化した。言い換えれば、研究者は質問に答えるだけで決定的に到達でき、LEAPS-Softwareの設定は自動的にスナップショットされる。結果として、目的ドリフトの余地を小さくする設計思想である。
フォームの各ステップは以下の通りである。
研究者は、データセットのCSVやTSVをテキストボックスに入力する。これを即座にバリデーションし、予期した形式になっているかを確認する。
研究者は、目標とする値をセレクトボックスで入力する。これを即座にバリデーションし、予期した形式になっているかを確認する。
研究者は、高度な設定を簡単に変更できる。これにより、ユーザーに自由度を増やし、研究の柔軟性を確保できる。
このステップを私たちが用意することで、ユーザーは迷いなく実行まで進むことができる。仮に、間違った入力があったとしても、適切なフィードバックをもとにしてユーザーが自身が修正できる。
ここでは、私たちがどのように計画したかを示す。
バックエンドは、フォーム型に合わせて決定的な入力と決定的な出力を最優先に置いた。まず、必要なパラメータをスキーマとして定義し、フォームを送信した時に設定をファイルとして保存する。次に、version1では考えていなかったタスクの管理を設計した。また、前回よりもセキュリティの強化を図るために、適切なアクセス制御を定義した。
フロントエンドは、段階的開示を原則に入力から出力までを画面遷移なしで完結させる計画とした。プロトタイプを作成してフィードバックを受けるというサイクルを繰り返すことで、高速な改善。各ステップで行われバリデーションは、型付きのスキーマとして定義することで実現し、フォームに無効な入力が存在する場合には送信前に弾くように設計した。また、フォームによって制限される自由度は、高度な設定を許容することで解決することとした。
さらに、意図しないLEAPS-Softwareの使用を未然に防ぐため、利用に関する情報開示を行うこととした。
ここでは、私たちがどのように設計したかを示す。
バックエンドは、モダンな技術を重視し、Neonをデータベースに、Vercel Blobをストレージとして採用した。ファイルの保存をストレージにし、ファイルの管理にデータベースにすることで、分責の原則に従った。
タスクには、状態を用意することで、計算資源の最適な利用を実現した。具体的には、「保留 / 実行中 / 成功 / 失敗 / 中断」を持つ状態変数を用意してキューで管理することで管理した。
フロントエンドは、モダンな技術を重視し、Next.jsをフレームワークに、shadcnをUIライブラリとして採用した。バリデーションにはReact Hook Fromとzodを用いて、型安全に管理した。即時バリデーションによるエラーのフィードバックを徹底した。
ここでは、私たちがどのように検証したかを示す。
バックエンドでは、実運用に限りなく近い条件で実際に使ってもらう検証を行った。データベースから収集したCSVファイルをそのまま投入してもらい、ジョブの受け付けからキューの追加、状態遷移などを通しで確認した。意図的にネットワークを遮断するなどを挟み、再開が決定的に動作するかを観察した。
フロントエンドは、本番を想定した利用を中心に据えた。研究者に初見でフォームに触ってもらい、新規登録から結果の確認までを、中断なしで到達できるかを観察した。エラーが発生した場面では、どの入力をどう直せばよいかが画面上だけで分かるかに注目し、説明文やプレースホルダの効き目を評価した。結果は、その場での修正率の高さに現れており、ガイダンスなしでデータセットを修正することができるケースが多かった。
version1と比べ、version2では曖昧さの排除の一段の強化が得られた。対話型からフォーム型に切り替えたことで、Tool Callingによる組み合わせの爆発が収束し、同じ入力から同じ出力へとまっすぐ辿れる。スナップショットが常に残るため、失敗時の復旧も手順通りに機械的に行えるようになった。さらに、ジョブを状態管理に移したことで、計算資源の分配がより容易に管理できるようになった。
version1で露わになった「最初の一歩が見えない」という壁は、version2のフォーム型で解けた。入力項目が段階的に開示され、必要な選択肢が目の前に並ぶことで、研究者は迷わず前に進める。即時バリデーションは、誤りを後でまとめて指摘するのではなく、その場で微調整を促し、手戻りの連鎖を断つ。自由度が下がる懸念はあったが、高度な設定のレイヤを用意したことで、熟練者は必要なときだけ踏み込める。結果として、実行までの時間が短くなった。フォームは「考えさせないUI」として機能し、version1で意図した学習コストの低さを、より素直なかたちで実現できた。
© 2025 - Content on this site is licensed under a Creative Commons Attribution 4.0 International license
The repository used to create this website is available at gitlab.igem.org/2025/tsukuba.
