build-agent

エージェントの構築

オーナーが毎週行っている作業を、名前を指定して依頼できる作業に変えます。

これにより、プラグインがあらゆる業界のワークフローをすべて搭載する必要がなくなります。どんなカタログでも、浄化槽業者の許可申請の手順や、保険代理店の保険会社別手数料の照合作業までは網羅できません。そうしたオーナー自身が作成できます。

ステップ 1 — 実際の作業を見るか、説明を聞く

始め方は 2 つあります。最初の方法のほうが、はるかに優れています。

最善の方法：この会話の中で、今まさに作業を終えたところです。 オーナーがファイルを取り出し、判断を下し、あなたを 2 回訂正しながら作業を一通り説明してくれたなら、その会話記録が仕様書になります。改めて聞き取りをするのではなく、会話記録から必要な情報を抽出してください。オーナーが行った訂正は最も価値のある部分です。オーナー自身がわざわざ言葉にしようとは思わない判断基準が、そこに含まれているからです。

そうでない場合：オーナーに説明してもらいます。 前回の作業について、具体的に順を追って説明してもらってください。抽象的な説明より、実際の詳細のほうがいつでも役に立ちます。「先週の火曜日に保険会社のファイルを取り出して、計上済みの内容と照合し、6 件の不一致を確認しました」と聞けば、「手数料を照合しています」より多くのことが分かります。

尋問のようにならずに全体像を把握する方法については、reference/capture.md を読んでください。

ステップ 2 — 変わる部分と、固定されている部分を分ける

このステップで求められるのは、まさにこの作業です。先週の火曜日の詳細をハードコードしたスキルは、先週の火曜日にしか使えません。

作業の各部分について、次のいずれかを判断してください。

• 固定 — 手順、情報源、出力形式、ルール
• 変動 — 日付、名前、金額、ファイル、顧客
• 判断 — オーナーが判断する部分。承認ゲートにします

作業を説明する中でオーナーが行った訂正は、多くの場合、判断が必要な箇所を示しています。「違います、そちらではありません。USD 50 未満のものはすべて対象外です」と言われた場合、それはルールです。「うーん、場合によります」と言われた場合、それは承認ゲートです。

ステップ 3 — 承認ゲートを見つける

送信、支出、公開、削除を行うすべてのステップには、承認ゲートが必要です。オーナーがためらったステップも同様です。

すべてにゲートを設けてはいけません。許可を 9 回も求めるスキルは、手作業よりもかえって不便です。重大な影響がある箇所と曖昧な箇所にゲートを設け、それ以外はそのまま実行できるようにしてください。

ゲートを設ける場所と、確認方法の表現については、reference/skill_authoring.md を読んでください。

ステップ 4 — 作成する

このプラグイン内のほかのスキルと同じ形式で、実際に使えるスキルを作成してください。フロントマターと番号付きの手順を含む SKILL.md と、必要に応じて reference/ フォルダーを用意します。

他のすべてのリリース済みスキルと同様、次の要件を満たす必要があります。

• 名前とフォルダー名は一致させ、小文字とハイフンを使う
• 説明では、何をするかだけでなく、どのような場合に起動するかも三人称で示す
• コネクターがない場合の実用的な代替手段を用意する
• 重大な影響のある操作には承認ゲートを設ける
• 数値を決してでっち上げない。不足しているデータは不足していると報告する

一般的なビジネス用語ではなく、オーナーの言葉で書いてください。 オーナーが「保険会社のファイル」と呼ぶなら、スキルでも「保険会社のファイル」と表現します。聞き慣れない用語ばかりのスキルでは、オーナーは安心して自動実行を任せられません。

ステップ 5 — 頼りにされる前に、実際の事例でテストする

オーナーがすでに答えを知っている事例、できれば実際に説明してくれた事例で、新しいスキルを実行してください。出力を、オーナーが手作業で得た結果と並べて確認します。

スキルが使われるかどうかを決めるのは、このステップです。正しいと分かっている結果を再現できるのを見たオーナーは、その作業をスケジュールするでしょう。そうでないオーナーは、毎回手作業で実行して確認することになり、何の効率化にもなりません。

一致しない場合はスキルを修正して、もう一度実行してください。オーナーに、惜しい結果を受け入れるよう求めてはいけません。

ステップ 6 — 登録して実行頻度を設定する

平易な言葉での依頼がスキルに届くよう、smb-router に追加し、オーナーが実際に使う起動フレーズを記録してください。

定期的な作業なら、スケジュール設定を提案してください。スケジュール設定によって、「実行できるスキル」が「自分が何もしなくても実行されるもの」に変わります。それこそが、オーナーが求めていた結果です。

Step 7 — 承認を得て共有する

チームと共有することを提案します。共有すると何が起きるのかを伝えます。つまり、誰が使えるのか、どのデータにアクセスできるのか、どこまで無人で実行できるのかを説明します。

スキルが送信、支払い、書き込みを行う場合は、リスクを具体的に伝えてください。 顧客にメールを送るスキルは、作成者ではなく、その前提を知らない人が実行する場合、現実的な危険を伴います。何かを送信する共有スキルは、下書きのみで使うことを推奨してください。

避けるべきこと

• たった今一緒に確認したタスクについて、もう一度聞き取りをしないでください。 やり取りの記録が仕様です。
• 例をそのまま固定しないでください。 名前、日付、金額は変わりますが、手順は変わりません。
• すべての手順に承認を求めないでください。 9回承認するくらいなら、手作業のほうがましです。
• テスト実行を省略しないでください。 テストしていないスキルは、いつまでも手作業で確認することになり、何の節約にもなりません。
• ありきたりなビジネス用語で書かないでください。 本人の言葉でなければ、信頼してもらえません。
• 承認なしで送信や支払いを行うものを作らないでください。 オーナーが望んだ場合でも、決して作らないでください。

作成後

オーナーは、名前を付けてトリガーまたはスケジュール設定できるスキルを手にしました。新しいスキルが未接続のツールを使おうとした場合、「ERP に接続して」（build-connector）が自然な次のステップです。未接続のシステムを、利用可能なデータソースにできます。関連する選択肢として、「概要を教えて」で新しい出力を日々の情報にまとめる方法や、スキルの内容を週次レポートに反映する場合の「月曜日の概要」もあります。提案は最大3つまでにし、このセッションですでにオーナーが断ったものは提案しないでください。

参考ファイル

• reference/capture.md — 詰問することなく、タスクの全体像を把握する方法
• reference/skill_authoring.md — 構成、フロントマター、承認が必要な箇所
• reference/gotchas.md — 誰にも使われないスキルを生む失敗要因