hachiflow.com
セットアップ

ワークスペースの準備はエージェントに任せる

MCP エンドポイントとエージェント優先の CLI を用意したのは、普段お使いのアシスタントにセットアップを任せ、人は人にしかできないことだけをするためです。私たち自身の使い方、2 社のクライアントを持つ代理店向けの小さな例、そしてまだ作っていない部分、つまりエージェントが自分でサービス料金を支払う仕組みについて書きます。

セットアップは、誰もクリックして進めたくない作業

新しいワークスペースには、エージェントの作成、指示文の記述、ツールの接続、スケジュールの設定が必要です。1 回なら問題ありません。10 件のプロジェクトや、代理店が受ける顧客ごとにとなると、フォームを埋めるだけで午後が終わります。

そこで、Waggle を普段お使いのアシスタントから操作できるようにしました。入口は 2 つあります。1 つは hachi、エージェント優先の CLI です。標準出力は毎回 JSON、エラーには型があり、終了コードは固定で、--dry-run があり、破壊的な操作には --yes が必要です。もう 1 つは MCP エンドポイントで、同じツールを任意の MCP クライアントに公開します。

どちらも現在利用できます。CLI は brew install hachiflow/tap/hachi で入り、hachi mcp serve でローカルの stdio サーバーが起動します。インストールせずに、https://api.hachiflow.com/mcp のホスト型エンドポイントを使うこともできます。どちらでもツールは同じです。

私たち自身の使い方

私たちは AI コーディングアシスタントをホスト型エンドポイントにつなぎ、約 10 件のプロジェクトを 1 つのファイルに書き出しました。プロジェクトごとにワークスペースがあり、それぞれにエージェント、コネクタ、スケジュールが入っています。アシスタントに hachi_plan を実行させて差分を確認し、そのあと hachi_apply を実行させました。

1 回の呼び出しで、エージェント、コネクタ、スケジュールまで揃った 10 個のワークスペースができました。10 回ビルダーをクリックして回る必要はありませんでした。

残ったのはワークスペースごとの認証情報です。ここは人が担当すべき部分で、あとで詳しく説明します。

代理店、クライアント 2 社、ファイル 1 つ

ある代理店が 2 社のクライアントを受け持ち、それぞれに受信箱担当とレポート担当のエージェントを置きたいとします。まず Claude Code にホスト型エンドポイントを追加し、いつもの hachiflow のログインでブラウザからサインインします。WorkOS AuthKit を使った OAuth なので、API キーを貼り付ける必要はありません。

次に、やりたいことを書きます。下の仕様が全体の形です。ワークスペースが 2 つ、エージェントが各 2 つ、受信箱担当には平日のスケジュールが付いています。エージェントにはクライアントごとの名前を付けています。一覧で見分けやすくするためです。

最初に plan を実行します。何も変更せず、apply が行う内容を表示します。そのあとで apply です。apply は宣言的で収束型です。もう一度実行しても「やることなし」と報告されるだけで、指示文を書き換えれば更新が 1 件になります。

agency.toml ファイル 1 つ、plan のあと apply クライアント A エージェント 2 つ コネクタ、スケジュール クライアント B エージェント 2 つ コネクタ、スケジュール handoffs 認証情報、招待 plan, apply
ファイル 1 つから、ワークスペース 2 つができます。人に戻ってくるのは、人が必要な短い一覧、つまり認証情報と招待だけです。
agency.toml
# ホスト型エンドポイントを追加し、ブラウザでサインインします $ claude mcp add --transport http hachiflow https://api.hachiflow.com/mcp # 仕様:ワークスペース 2 つ、エージェント各 2 つ version = 1 [[workspace]] key = "client-a" name = "Client A" [[workspace.agent]] name = "client-a-inbox" instructions = """Triage Client A issues.""" runtime = "claude" connectors = ["github"] [[workspace.agent.schedule]] title = "morning-triage" prompt = "Summarize what changed overnight." hours = [9] minutes = [0] weekdays = ["mon", "tue", "wed", "thu", "fri"] timezone = "America/Denver" [[workspace.agent]] name = "client-a-reports" instructions = """Write Client A's weekly report.""" runtime = "claude" connectors = ["github"] [[workspace]] key = "client-b" name = "Client B" [[workspace.agent]] name = "client-b-inbox" instructions = """Triage Client B issues.""" runtime = "claude" connectors = ["github"] [[workspace.agent.schedule]] title = "morning-triage" prompt = "Summarize what changed overnight." hours = [9] minutes = [0] weekdays = ["mon", "tue", "wed", "thu", "fri"] timezone = "America/Denver" [[workspace.agent]] name = "client-b-reports" instructions = """Write Client B's weekly report.""" runtime = "claude" connectors = ["github"] # まず確認し、それから apply します $ hachi plan -f agency.toml $ hachi apply -f agency.toml

例のすべてです。ファイルに秘密情報は含まれません。コネクタのサインインとワークスペースごとのモデル認証情報は、人が仕上げる handoffs として返されます。

準備はアシスタントに、秘密情報は人に

apply は、何でもできるふりをしません。人にしかできない手順を「handoffs」として返します。コネクタの認証情報、ワークスペースごとのモデル認証情報、招待がそれです。それらが済んだあとで plan をもう一度実行すると、変更なしの項目だけになるはずです。

秘密情報は仕様ファイルには入れず、モデルを通ることもありません。認証情報はエスクローに保管され、エージェントが受け取るのはリースであって、値そのものではありません。認証情報はあえてワークスペースごとに分けています。代理店のクライアントはそれぞれ自分のキーと自分のアクセス権を持っており、アカウント全体で共通のキーが 1 つあると、その境界があいまいになるからです。

入力作業はアシスタントが行い、信頼が必要な部分、つまり各クライアントのツールに一度サインインする作業は人が行います。

代理店に向いている理由

代理店のセットアップは、もともと繰り返しの多い作業です。クライアントごとにワークスペースがあり、そのクライアント名の付いたエージェントが数個、毎回ほぼ同じコネクタ、そして朝のスケジュールがあります。名前を差し替えるだけのテンプレートで、エージェントが得意とする仕事です。

ファイルをバージョン管理しておけば、クライアントの追加は数行の追記と、確認のための plan だけで済みます。セットアップは代理店のアシスタントが行い、handoffs は代理店のメンバーが行います。エージェントの実行については何も変わりません。引き続き、そのエージェントが属するアカウントのマシンで動きます。

セットアップは無料、エージェントの実行は有料

アカウントがあれば、プランもマシンもなしで、ワークスペースの作成とエージェントの設定ができます。そうして作ったエージェントは、動かす場所ができるまで待機します。費用がかかるのはエージェントを実行するときだけで、実行には計算資源が必要だからです。

これは意図した設計です。アシスタントが全体を組み立て、カードの入力を求められる前にその内容を確認できるべきだと考えています。支払うのは作業が始まるときで、計画の段階ではありません。

次の段階:エージェントが自分でサービスを購入する

この部分は計画中で、まだ作っていません。私たちが目指しているのは、エージェントが HTTP 402 を使い、Stripe のマシン決済(Shared Payment Tokens を使う Machine Payments Protocol)でサービス料金を自分で支払える形です。Stripe Projects のプロバイダーになるための申請と、Stripe Directory への掲載申請は出していますが、どちらもまだ承認されていません。今の時点では、この仕組みは動きません。

後半は、同じく計画中のクレームフローです。エージェントがすべてを準備し、クレームリンクを送ると、本人は頼んだとおりのワークスペースにそのまま入れます。本人に残る作業は秘密情報の入力だけです。

現在は、エージェントがセットアップを行えますが、アカウントの作成と、エージェントを動かすためのプランの選択は人が行う必要があります。大事な判断から人を外さずに、この隔たりを埋めることが目標です。

現在使えるものと、これから

現在使えるもの:hachi CLI、ローカルとホスト型の MCP、1 つのファイルからの plan と apply、認証情報の handoffs、無料のセットアップ。計画中のもの:HTTP 402 でのエージェントによる支払い、そしてクレームフロー。代理店を運営していて、使える側を試したい場合は、上のエンドポイントと例だけで始められます。

← フィールドノート一覧