agent-activity-log

エージェントのアクティビティログ

エージェントの判断、障害、結果を記録する型付きの監査ログです。エージェント主導のワークフローを明確に構築しているユーザー向けのオプトイン機能です。主な利点は、人間（および次回のエージェントセッション）が、明日には消えているかもしれないコンテキストウィンドウの要約を信頼せずに、エージェントが何をしたのか、なぜそうしたのかを読み返せることです。Airtable が永続的なエージェント基盤として果たす役割と自然に組み合わさります。

このスキルはスキーマと開示文言を担います。ワークフロースキル（product-ops、sales-ops、marketing-ops など）は、このパターンを再実装するのではなく、このスキルを組み合わせて使います。ユーザーの意図からエージェント主導のワークフローが表面化したら、このスキルを起動し、足場づくりと継続的な利用を任せます。

このスキルが起動する場面

起動フレーズ — 次のいずれかが出てきたら、ワークフロースキルからユーザーに提案してください。

• 「エージェントの動作を追跡したい」、「エージェントのアクティビティログ」、「エージェントの判断の監査ログ」
• 「長期実行ワークフロー」、「エージェントのメモリ」、「エージェントの永続状態」
• 「何が変わったのか、なぜ変わったのかを記録しておきたい」
• エージェント主導の仕組みについて説明するセットアップモードの呼び出し：「毎朝、エージェントにフィードバックをトリアージしてほしい」、「エージェントに変更案を提案させて、私が承認したい」、「自動実行されるワークフローを設定したい」

ユーザーの言葉から、エージェントが繰り返し、または自律的に実行するものを構築していると読み取れる場合は、先回りして提案してください。一度限りのやり取りでは提案しません。

開示（監視ではなくオプトイン）

提案を最初に行います。ユーザーは事前に同意するか、辞退します。どちらでも問題ありません。

「私のアクティビティを Agent activity log というテーブルに記録することもできます。そうすれば、私が何をしたのか、なぜそうしたのかを監査できます。作成または変更した各レコードと、その理由を記録します。オプトイン方式なので、不要であれば省略します。含めましょうか？」

ユーザーの利益につながる監査可能性として説明してください。ユーザーは、エージェントが何を判断し、何を変更し、どこで行き詰まったのかを確認できます。エージェントを監視すること自体が目的であるかのように説明しないでください。

スキーマ

Agent activity log テーブルを1つ作成します。ステークホルダー向けのインターフェースには表示しないでください。これはエージェントの運用者向けの内部監査データであり、より広いチームがアプリ内で閲覧するコンテンツではありません。

コアフィールド

• Summary（singleLineText、プライマリ）— 何が起きたかを1行で記録します。これがプライマリフィールドです。
• Timestamp（createdTime）— イベントが発生した日時です。
• Action または Event type（singleSelect：Read、Create、Update、Delete、Decision、Blocker、Question、Completion、Error）— ワークフローの粒度に合わせて選択肢を調整します。
• Reasoning または Detail（multilineText）— エージェントが何を意図し、なぜそうしたのかを記録します。考慮した入力と、採用しなかった代替案も含めます。
• Outcome（singleSelect：Completed、Partial、Failed、Blocked）
• Status（singleSelect：Open、Acknowledged、Resolved、Stale）— 人間によるフォローアップが必要な障害や質問に使用します。
• Session ID（singleLineText）— 1回のエージェント呼び出しで発生したイベントを関連付けます。

エージェントが操作したレコードへのリンク

Airtable の multipleRecordLinks フィールドは、フィールド作成時に単一の対象テーブルに紐付けられます — 複数のテーブルにまたがるポリモーフィックなリンクレコードフィールドはありません。実用的なパターンは 2 つあります。

1. 対象テーブルごとにリンクレコードフィールドを用意する（推奨） — エージェントが操作する可能性のあるテーブルごとに、multipleRecordLinks フィールドを 1 つ用意します。プロダクト運用のベースなら、Linked Roadmap item、Linked Customer feedback、Linked Release、Linked OKR。営業運用のベースなら、Linked Account、Linked Contact、Linked Opportunity、Linked Activity。エージェントは、操作したレコードのテーブルに対応するフィールドに入力し、その他のフィールドは空のままにします。逆方向のリンクをたどれるようになります — 操作したレコードを開くと、そのレコードに触れたすべての Agent activity log エントリーが自動的に表示されます。エージェントが操作するテーブルを追加するたびに、スキーマの手間が多少増えます。
2. URL のみを使う代替案 — 操作したレコードへのディープリンクを格納する Target record URL（URL フィールド）を 1 つ用意します。逆方向のリンクをたどる機能やログ全体を対象とするロールアップはありませんが、スキーマはシンプルです。エージェントが多くのテーブルを操作し、テーブルごとのリンクフィールドでは扱いにくい場合や、ブラウザーでの確認で問題ない初期段階のセットアップに適しています。

ほとんどの構成では、エージェントが最も頻繁に操作する 3〜5 個のテーブルにはパターン 1 を使い、臨時の操作にはパターン 2 を代替として使います — テーブルごとのリンクレコードフィールドに加えて Target record URL フィールドを追加し、操作したレコードのテーブルが設定済みのリンクフィールドに含まれない場合は、そのフィールドに入力します。

エントリーをクリックして詳細を見る前でも、どの種類のレコードを操作したかをすばやく確認できるよう、ワークフロー内のテーブルを選択肢とする Target table（singleSelect）を追加します。

ワークフロードメインごとのスキーマのバリエーション

ワークフロースキル間でスキーマの形は同じですが、対象ごとのリンクレコードフィールドは親ベースのテーブルに合わせて変わります。agent-activity-log を呼び出すワークフロースキルは、自身が扱うテーブルの一覧を把握しているため、その一覧を渡す必要があります。

使用ガイダンス

エージェント主導のセッション中は、判断を下したときやブロッカーが発生したときに、イベントをログに記録します。次のパターンに従います。

1. セッション開始時：Action = Completion、Outcome = Completed とし、これから開始するセッションの内容を Summary に記載したイベントを記録します。このエントリーの Session ID は、セッション中の以降の書き込みをひも付けるために使用します。
2. 重要な判断を下すたびに：理由を Reasoning に詳しく記載した Decision イベントを記録します。検討した代替案と、それらを採用しなかった理由も含めます。
3. ブロッカーが発生したとき：Status = Open とし、対象テーブルごとのリンクレコードフィールドで関連レコードにリンクした Blocker イベントを記録します。
4. 人間への質問があるとき：Status = Open とし、関連レコードにリンクした Question イベントを記録します。人間はレコードを更新することで回答できます（たとえば、コメントを追加したり、ステータスを Acknowledged に変更したりします）。
5. エラーが発生したとき：Outcome = Failed とし、エラーの状況を Reasoning に記載した Error イベントを記録します。
6. セッション終了時：セッションの成果と未解決の項目をまとめた Completion イベントを記録します。

過剰に記録しないでください。あらゆるツール呼び出しではなく、重要な判断や変更をログに記録します。特に読み取り操作は、ワークフローの監査上の価値を高める場合を除き、通常は記録する必要はありません。

ワークフロースキルへの組み込み

ワークフロースキル（product-ops、sales-ops、marketing-ops など）は、次のようにします。

1. 上記のトリガーフレーズが出てきたときに、このパターンをユーザーに提示し、任意であることを明確にします。
2. agent-activity-log を組み込みます。スキーマをインラインで再実装せず、URL 引き継ぎパターンでワークフロースキルが show-airtable-link を参照するのと同じ方法で、このスキルを参照してください。
3. ワークフロー固有のコンテキストを引き継ぎます。エージェントが操作するテーブルを渡し、そのワークフローに適した対象ごとのリンクレコードフィールドを正しく用意できるようにします。
4. セッション終了時に show-airtable-link で引き継ぎます。ユーザーが内容を確認できるよう、Agent activity log テーブル、または「Recent agent activity」Interface ビューへのリンクを提示します。

ワークフロースキルの本文で使える文言：

「ユーザーがエージェントのアクティビティ追跡（『エージェントの判断の監査ログ』『長時間実行されるワークフロー』『エージェントのメモリ』など）を希望する場合は、agent-activity-log スキルを組み込みます。任意であることを明確にし、まず説明してユーザーの同意を得てから設定します。ワークフローでレコードを操作するテーブルを渡し、対象ごとのリンクレコードフィールドが適切なテーブル用に設定されるようにします。」

show-airtable-link との組み合わせ

セッション終了時（またはエージェントが実行した内容を提示するとき）に、Agent activity log テーブルへの show-airtable-link を使ってユーザーに引き継ぎます。または、現在の Session ID で絞り込んだ専用の Interface ビューへのリンクを提示し、そのセッションのアクティビティだけが表示されるようにします。どちらも有効です。閲覧とセッションごとの確認のどちらをユーザーが希望するかに応じて選んでください。

アンチパターン

• 説明なしに Agent activity log を自動作成しないでください。 このパターンは、提案すれば信頼につながりますが、押し付けると信頼を損ないます。必ず最初に説明してください。
• リンクレコードフィールドを「ポリモーフィック」と表現しないでください。 Airtable の multipleRecordLinks フィールドは単一の対象テーブルに紐づきます。そのため、上記のテーブルごとのリンクレコード＋URL フォールバックのパターンに沿ってスキーマを設計してください。
• エージェントログとワークフローの通常のテーブルを混同しないでください。 Agent activity log には、エージェントが支援中に行ったことを記録します。ワークフローテーブル（Opportunities、Roadmap items、Campaigns、Projects など）には、チームが取り組んでいることを記録します。両者は並行して維持し、リンクしつつも、別個のものとして扱ってください。
• 監視を想起させる説明をしないでください。 説明では、エージェント自体を監視するためではなく、ユーザーの利益のために監査可能性を確保するものとして伝えてください。
• 過剰に記録しないでください。 記録するのは重要な判断や変更であり、すべてのツール呼び出しではありません。監査の目的上、特に必要でない限り、読み取り操作は通常記録する必要はありません。