はてなブックマーク

はじめに 先日、Acsim 開発に使用している query-db というスキルを postgres-mcp 前提の構成から、Deno ベースの read-only query フローに刷新しました。 これは単に使うツールを入れ替えた話ではありません。「手作業が多い運用タスクを、Agent Skills でどう扱うべきか」というタスクの設計方針の延長にある変更です。 すべてをエージェントの自律性に丸投げするわけではなく、エージェントが自律的に判断する部分とコードで厳密に守る部分をうまく分けることで、柔軟かつ安全な運用ができるのではないか、というのがこの取り組みの根底にある考え方です。 Agent Skills はその境界面として非常に使いやすく、この考えのもとに、Acsim では Agent Skills でできることを広げている最中です。 今回の query-db はその具体例にあたります

ここからは、先進企業がこの考え方をどう実践しているかを掘り下げます。 先進企業の実践 OpenAI、Anthropic、Stripe。 規模もプロダクトも異なる3社ですが、実践には共通パターンがあります。 企業ごとではなく、テーマ別の横串で整理します。 エンジニアの役割の変化 AIにコードを書かせること自体は、もう多くのチームが実践しています。先進企業のエンジニアが異なるのは、その過程にほとんど介入していないことです。 OpenAIでは、3名のエンジニアが「手書きコード一切禁止」の制約でCodexだけで社内向け製品を構築しました1。エンジニアの仕事は、タスクの優先順位付け、ユーザーフィードバックの受け入れ基準への変換、成果の検証、そしてエージェントが苦戦したときに「何が足りなかったか」を特定して環境にフィードバックすることです。 Anthropicでは、Claude Codeの開発責任者で

全体像: リクエストから RLS ポリシー評価まで Acsim では、1つの HTTP リクエストが RLS で保護されたデータにアクセスするまでに、次の流れを辿ります。 �7 �� テナントコンテキスト（所属テナントやロールなどの情報）は「Middleware → Hono Context → UseCase → PostgreSQL」の順に流れます。Middleware がテナントコンテキストを取得・検証して Hono Context に格納し、UseCase がそれを取り出して PostgreSQL のトランザクション内でセッション変数に注入し、RLS ポリシーが評価します。 ここからは、この構成に至る過程で直面した設計判断を3つ掘り下げます。 設計判断 1: テナントコンテキストをどう取得するか RLS にテナントコンテキストを渡すには、リクエストからテナントコンテキストを取得して