パート1では、ReisekiのReActループの背後にある6つの技術的な問題——イテレーション上限、コンテキスト管理、永続的メモリ、そしてセキュリティ——を取り上げました。まだ読んでいない場合は、こちらから始めてください。
このパートでは設計上の判断について話します。最初に頭に描いていた構想はありましたが、実際のレイアウトはテストを重ねる中で時間とともに発展していきました。私は次の質問をしました。これは誰のためのものか？ユーザーが調整すべきことと、自動化すべきことは何か？そして、ファイルにアクセスでき、会話を記憶するエージェントに対して、可能な限り透明性を高めるにはどうすればいいのか、です。
Reisekiはオープンソースです：github.com/Flo1632/reiseki
異なる方向へ引っ張った2つの目標
Reisekiは、常にうまく両立できるわけではない2つの原則を前提に設計されました。
1つ目：技術的な知識がなくても使えること。 ターミナル不要、Python不要、設定ファイル不要です。アプリをインストールできるなら、Reisekiを動かせます。
2つ目：ユーザーは常に、エージェントが自分について何を知っているのかを把握できること。 記憶、会話履歴、ファイルアクセス——それらすべてを可能な限り見える化し、いつでも削除できるようにします。
その緊張関係は、透明性はしばしば複雑さを意味するという点にあります。ユーザーを圧倒せずに、適切な情報をどう提示するか。
私はそれを次のように考えました。
6つのUX/UI課題と、それをどう解決したか
セットアップ不要——ダウンロードして始めるだけ
課題： アプリをインストールできるなら、Reisekiを実行できるべきです。その他のすべて——モデルの設定、データベースのセットアップ、...——は、裏側で見えない形で行われるべきです。
解決策： ReisekiはWindowsインストーラーとして提供されます。インストール時にワークスペースのフォルダを選ぶだけで、それ以外は不要です。Python環境を設定する必要も、編集すべき設定ファイルも、コマンドラインもありません。Ollamaをインストールして、モデルをダウンロードしてある前提で、エージェントはセットアップ画面で名前と、目標の短い説明を尋ねたあと起動し、そのまま使える状態になります。
インストール中のワークスペース設定や、Reiseki-App内でドロップダウンメニューからモデルを変更できるようにするというアイデアは、私がテストしていた最終のバージョン0.1.3および0.1.4の段階で入ってきました。
ライブツールのトレース
課題： モデルが何をしているのかをどう示し、透明性を生み出すためにそれをユーザーにどう見えるようにするか。
解決策： エージェントがツールを呼び出すたびに、UIにリアルタイムで表示します。どのツールが呼ばれたのか、どんな引数で呼ばれたのか、そして何が返ってきたのか、を明確にします。
メモリ管理パネル
課題： 完全な透明性のために、メモリをUI上で直接見えるようにしたい。
解決策： 初期バージョンではメモリ保存の自動化を考えましたが、小さなモデルはシステムプロンプトに含まれていても、自動化を忘れがちです。そこで、ユーザーに「Save-Memory」ボタンを用意し、実際にはsave_memoryツール呼び出しをトリガーするようにしました。利点は、会話を保存する価値があるかどうかの判断をユーザーが行う点にあります。エージェントが決めるのではありません。
また、上部にもメモリパネルがあり、保存されたすべてのメモリを確認でき、1クリックで個別のエントリを削除できます。忘れるようにエージェントに頼み、従ってくれることを期待するのではなく、直接削除します。あなたに関するエージェントの知識は、編集可能なリストです。
会話履歴モーダル
課題： チャットログの透明性と編集可能性
解決策： チャットログはセッションをまたいでSQLiteに保存されるため、エージェントは過去の会話の記録を持っています。履歴モーダルによってそれが見えるようになり、削除ボタンも用意されます。ログ全体はいつでもクリアできます。
QRトグルによるスマートフォンアクセス
課題： アプリなしで、できるだけ簡単にスマートフォンから利用できるようにすること。
解決策： エージェントはローカルWebサーバーとして動作します。つまり技術的には、同一ネットワーク上の他のデバイスから到達可能ですが、明示的に有効化した場合に限ります。QRモーダルには、このためのトグルがあります。オンにすると、スマホで読み取れるQRコードが表示されます。オフの場合は、中間層（middleware）の段階でサーバーがlocalhost以外へのすべての要求をブロックします。
ここでの重要な設計上の判断は、ユーザーにこの機能を制御させること＋簡単にアクセスできるようQRコードを使うこと、の2点です。
モデルスイッチャー
Ollamaは複数のモデルをサポートしており、それらの切り替えは一般的なワークフローです。たとえば、素早い質問にはより高速なモデルを使いたいし、複雑なタスクにはより能力の高いモデルを使いたいことがあります。モデル変更のためにサーバー再起動を要求すると、不要な摩擦が生まれます。
課題： モデル切り替えをできるだけ簡単にすること。
解決策： モデルスイッチャーはUI上で直接変更できるようにしています。変更は次のメッセージから反映されます。すでにOllama内で事前にモデルをダウンロードしてあるなら、OllamaとReisekiの間で切り替える必要はありません。
追加の考え
「日常のユーザーにとってシンプルにすること」と、「できるだけ少ないRAMで動かすこと」、さらに「できるだけ機能は維持すること」の間にある緊張関係は、完全には解消されません。ただ管理されるだけです。次回は、いくつかを別のやり方で進めたいと思っています。
裏側のデータベースは優れたシンプルな土台ですが、私はClaudeのMarkdownファイル方式がとても好きで、これによってさらに柔軟性が高まると思います。（Claude Codeのセッション中にClaude.mdや他のmdファイルを使いましたが、すごくうまくいきました！）
最初のセットアップとユーザーガイダンス：最初に、チュートリアルとして自動化されたセッションや動画のようなものがあれば、ユーザーがさまざまな機能をより良い形で見つけられるようになるのでは、と思っています。
小型モデルのトレードオフ：開発中、Qwen 2.5-coder:7BからGemma 4:e2bへ切り替えました。その結果、エージェントとツール呼び出しが大幅に改善されました。今後、さらに先進的な小型モデルが登場することを期待しています。一方で、より多くのコンテキストや大きなモデルがあれば、パート1で説明したいくつかのコーディング上の課題は無用になるでしょうし、一般的にさらに良い体験につながるはずです。とはいえ、現時点では全部を手に入れることはできません。
このプロジェクトは完全にClaude Codeで作られました。技術的な判断と設計目標は私のものです。Claudeが実装を担当しました。
非技術者向けのツールを作るとき、どんなUX/UIの問題に遭遇しましたか？あなたの経験をぜひ聞きたいです
