kiuribotsとは――調査と開発を任せる自作AIエージェント
元々はOpenAIのDotsを使ってAIに作業を依頼していたのですが、Dotsの仕様なのかDotsに割り当てられている内部のVM（仮想マシン）のクリーンアップや、作業を続ける際の整合性に困ることがあり、自作を考えるきっかけになりました。
OpenClawやHermesも考えましたが、まずは自作で諸々考える方が良いかなと思い開始しました。
まず欲しかったのは、DotsのようにAIへ仕事を任せながら、記録の残し方や作業の進め方を自分で調整できる仕組みでした。
最初に作ったのは、複数のモデルを呼び分けて作業を進めるBotsエージェントでした。
自分で調整できる仕組みにしたかった
役割に応じて複数のAIモデルを呼び分け、その結果をつないでいく仕組みを「オーケストレーション」と呼びます。kiuribotsはこの仕組みを土台にしています。
そこへ、依頼を受ける窓口や、会話とタスクの記録、さらに定期的に状態を見回って次の仕事を提案する処理を組み合わせました。モデルへ質問を投げるところから、成果物を確認し、最終的な変更を反映するところまで、すべての工程に自分で手を入れられるようにすることが狙いです。
kiuribotsとは何か
私が作っているkiuribotsは、調査やソフトウェア開発を手伝う自分用のAIエージェント群です。既存のLLM（大規模言語モデル）に役割ごとの依頼を渡し、受付、履歴の保存、実行の許可をプログラムで支えています。
依頼が作業と反映へ進む流れ
たとえば「READMEの誤字を直して」と頼んだ場合、内部では次のように処理が進みます。
- パートナー（相談役）が利用者の依頼を整理し、受付プログラムであるGatewayにタスクの作成を求めます。
- 作業係（Worker）がタスク専用の作業クローンでREADMEを編集し、コミットを作成します。
- テストとレビューの結果を記録します。ここでは、レビューによる「品質として問題なし」という評価と、変更を反映してよいという「利用者の許可」を別物として扱います。
- Gatewayが反映の許可を確認し、送るコミットがその許可の対象と一致することを確かめてから、作業用ブランチ
bot/task-<id>へpushします。
このように、コードを編集する作業係のモデルが、外部のGitリポジトリへの反映まで直接行う構成にはしていません。
kiuribotsに何を任せているか
普段任せている仕事は、技術ドキュメントの調査、指定したコードの修正とテスト、リポジトリの定期チェックなどです。
管理画面は、OSSの開発者ポータルであるBackstage上に自作のkiuribotsプラグインとして載せており、依頼の送信、進捗の確認、承認操作を一箇所にまとめています。また、Slackからの依頼や通知にも対応しています。
データの管理については、タスクや会話の履歴をSQLiteのDBに保存し、成果物と作業履歴は作業用フォルダおよびGitに残す形にしています。
主な係とAIを使わない窓口（Gateway）
先ほどのREADME修正の流れに登場した役も含め、kiuribotsを構成する主な役割を整理すると次のようになります。
* パートナー（相談役）：利用者との対話、依頼の解釈、進行中の目標管理を担当します。返答や判断の記録は書き込めますが、タスクの承認や緊急停止スイッチを操作する権限は持っていません。 * ウェブ係（Searcher）：Web検索や公開資料の取得を担当します。検索・取得とファイル参照の標準ツールのみを持ち、ファイル編集やシェル実行のツールは渡していません。 * 作業係（Worker）：タスクごとに用意された作業クローンでコードを調査・編集し、テストを行います。正規の反映処理では、外部リポジトリへのpushやmergeはGatewayを通して行います。 * 定期チェック係（Scout）：定期的にリポジトリ等の状態を調べて改善タスクを提案します。タスクの状態遷移や反映の許可を決める権限は持っていません。 * レビュー係：作業係が作った変更内容を評価します。このレビューはあくまで品質面の確認であり、利用者による反映の許可とは区別されます。 * Gateway：AIモデルを持たない制御プログラムです。依頼の受付、状態の記録、許可のルールの判定、そして許可されたコミットの外部反映を担当します。 * Maintainer（管理者）：システムの構成や権限設定を変更できる人間の管理者です。
反映の窓口となるGatewayにはLLMを置かず、許可の確認とGitへの送信をプログラムで行います。