はじめに AWS DevOps Agent の調査において、最初の課金対象クエリを実行する前に、どれくらいの費用がかかるかを確認の上、利用するかどうかを判断できます。Investigation Cost Guardrail スキルは、 AWS DevOps Agent にコスト意識をもたらし、調査の開始前にどこまで調べるかをチームが把握・制御できるようにします。 本記事では、オープンソースの AWS DevOps Agent スキルである Investigation Cost Guardrail を紹介します。このスキルは、Amazon CloudWatch、AWS X-Ray、Amazon Athena、Amazon DynamoDB、Amazon S3、AWS CloudTrail といった設定済みの AWS サービスや、サードパーティーツール、エージェント自身のネイティブツールをまたいでエージェントが実行するオペレーションを分類します。そのうえで、見積もり時点における対象リージョンの最新料金を取得します。本記事では、仕組みを説明し、具体的なシナリオを示しながら、自律型 AI にとってコスト意識がセキュリティガードレールと同じくらい重要になりつつある理由を解説します。 DevOps の考え方は、開発と運用の間にあるサイロを取り除くことです。AWS DevOps Agent も同じ原則を体現しています。アプリケーションに関する知識と運用の専門知識の隔たりを埋め、両方の領域を横断してデバッグできる、チームのもう一人の SRE のように機能します。DevOps の考え方が文化とプラクティスをもたらすのに対し、エージェントは自律的な実行をもたらします。 「You build it, you run it（作った人が運用する）」が説明責任を意味していたのに対し、AWS DevOps Agent が目指すのは、大規模環境における持続可能性です。チームの専門知識を 24 時間 365 日利用できるように拡張することで、システムが成長し、単一のチームだけでは監視しきれなくなっても、このオーナーシップモデルを維持できるようになります。 本記事のシナリオとコストの数値はあくまで例です。実際のコストと結果は、リージョン、データ量、現在の AWS 料金によって異なります。 安心して任せるための原則：場数で培われるコスト感覚 あるアクションにどれくらいの費用がかかるかを見積もることは、クラウドで身につけるのが最も難しい感覚の一つです。広範なクエリやテーブル全体のスキャンから学び、実行前にスコープを絞ることが自然にできるようになるまで、時間をかけて身につけていくものです。 AWS DevOps Agent は、シニア SRE が持つ自律性と高度な調査能力をもたらします。このガードレールを使うことで、エージェントは初日から同じコスト意識を備え、実行する各アクションに一貫して適用します。経験豊富なエンジニアが本能的に実践するのと同じ規律で、実行前にスコープとコストを見積もります。 AI ガードレールを取り巻く状況 AI ガードレールとは、AI システムが安全かつ責任を持って、定義された境界内で動作し続けるための安全装置です。AI モデルがどのように出力を生成し、アクションを実行するかを統制するポリシー、技術的な制御、監視の仕組みが含まれます。 ガードレールに関する議論の多くは、コンテンツの安全性、プロンプトインジェクションの防止、意図しない情報開示に焦点を当てています。これらは重要ですが、AI エージェントが「考える」段階から「行動する」段階に移った瞬間、もう一つの側面が極めて重要になります。それは、アクションを実行する前に、そのアクションのコストを把握することです。 従来のソフトウェアのコストは決定論的です。API コールのコストは、呼び出す前にわかります。一方、自律型エージェントは、どの API を呼び出すか、何回呼び出すか、どのスコープを対象にするかを動的に判断します。このスキルにより、こうした動的なコスト構造を事前に可視化し、調整できるようになります。これにより、コストは調査において明示的に考慮される判断材料になります。 AI エージェントの責任共有モデル AWS DevOps Agent では、責任共有モデルを自律型エージェントにまで拡張できます。 AWS DevOps Agent は、調査機能と、それを統制するためのエージェント指示やスキルなどの制御手段を提供します。 利用者はガードレールを設定し、しきい値を決め、エージェントが動作する境界を定義します。 実際の運用で定着するガードレールには、次の 3 つの共通点があります。 必要に応じて有効・無効を切り替えられる（オプトインまたはオプトアウト） 理解するための専門知識が不要 介入時に明確なガイダンスを提供する これが、このガードレールの設計思想です。クラウド料金の専門家にならなくても、コストの透明性を得られます。 AWS DevOps Agent スキルとは コストガードレールの詳細に入る前に、スキルとは何か、そしてエージェントインストラクションとどう違うのかを理解しておくと役立ちます。 スキルは、調査手順と運用ナレッジをまとめた再利用可能なパッケージです。現在のタスクに関連する場合、エージェントによってオンデマンドで読み込まれます。これにより、AWS DevOps Agent は汎用アシスタントから、利用者のインフラストラクチャに精通したスペシャリストへと変わります。 最もシンプルな形では、スキルは SKILL.md とオプションの参照ファイルを含むディレクトリです。 SKILL.md ファイルには、次の内容が含まれます。 フロントマター：名前と説明 エージェントが調査中に従う段階的なインストラクション description フィールドは非常に重要です。エージェントはこのフィールドを使って、そのスキルを読み込むかどうかを判断します。調査が始まると、エージェントは利用可能なすべてのスキルの説明を読み、関連するものを選択します。複数のスキルを同時に読み込むこともできます。 スキルとインストラクション：スーパーパワーと基本命令 AWS DevOps Agent には、運用ナレッジを注入するための 2 つの仕組みがあります。   スキル エージェントインストラクション（AGENTS.md） 読み込まれるタイミング オンデマンド（エージェントが説明と現在のタスクを照合） 常時（無条件、すべてのセッション） コンテンツ形式 Markdown、または補助ファイルを含む ZIP バンドル Markdown のみ、補助ファイルなし 適用範囲 特定のイベントタイプに特化 セッションをまたいで適用されるグローバルポリシー 例えるなら 必要なときにエージェントが発動するスーパーパワー エージェントが常に従う基本命令 ユースケース 調査手順、トラブルシューティングのプレイブック セキュリティポリシー、コーディング標準、組織のガイドライン エージェントインストラクションは、すべてのセッションで無条件にエージェントのコンテキストへ注入されるシステムプロンプトです。常に適用しなければならない常設ポリシーには、インストラクションを使用します。 スキルは、関連するときにだけオンデマンドで読み込まれるスーパーパワーです。参照ファイル、メトリクステーブル、複数ステップの手順を含めることができ、必要のないセッションに読み込むと無駄になるような、深く専門的な能力を表現します。 重要な違いは、インストラクションがエージェントにどのように振る舞うかを教えるのに対し、スキルは特定の問題をどのように調査するかを教える点です。 ソリューション概要：調査コストガードレールのワークフロー 次の図は、調査におけるコストガードレールの位置を示しています。エージェントが調査対象リソースを特定した後、課金対象クエリを実行する前という、可能な限り早い段階でワークフローに介入します。 図 1：AWS DevOps Agent における Investigation Cost Guardrail スキルの仕組み 仕組み：4 層アーキテクチャ 各 AWS サービスの各操作について課金対象かどうかをハードコードするのではなく、このスキルは上の図 1 に示した 4 層アーキテクチャを使用します。これらの層は連携して、レジストリに登録されていないサービスやエージェント自身のネイティブツールも含め、AWS サービス全体の操作を分類します。 Layer 0：ネイティブツールの分類 エージェント自身の各ツールには、課金対象か非課金対象かが明示されています。PromQL（ get_prometheus_metrics ）、 use_splunk とその他のサードパーティー統合、shell、サブエージェントの起動はすべて分類されます。 use_aws もこれらと同様ですが、後続のレイヤーでさらに詳細に分類されます。 Layer 1：ヒューリスティックルール 動詞に基づく分類は、レジストリに記載されていないサービスも含め、サービスを横断して機能します。Describe、List、Get、Lookup、Check、Validate、Tag、Untag はメタデータを返すもので、通常はデータスキャンの料金が発生しません。Query、Scan、Execute、Invoke、Insights などの動詞はデータを処理またはスキャンするため、課金対象として扱われます。多数のページにわたるページネーションを伴う広範な List や Describe の呼び出しには、注意フラグが付けられます。 Layer 2：既知の有料操作レジストリ 有料操作について、レジストリは、正確な計算式と、料金を取得するために使用する AWS Price List API のフィルターを保持しています。レジストリ自体は料金を保持しません。 Amazon CloudWatch （Logs Insights、GetMetricData、GetInsightRuleReport、Live Tail、スキャンされた PromQL サンプルを含む）、 AWS X-Ray 、 Amazon Athena 、 Amazon DynamoDB 、 Amazon S3 のリクエストが対象です。運用担当者は独自のエントリーでレジストリを拡張できます。 Layer 3：自己学習型のレスポンス検証 操作の実行後、スキルは BytesScanned 、 ConsumedCapacity 、 TracesProcessedCount など、課金対象の使用量を示すフィールドがレスポンスに含まれていないかを確認します。以前は未分類だった操作がこれらのフィールドのいずれかを返した場合、スキルは調査の残りの期間、その操作を課金対象として分類します。これにより、調査が進むにつれてカバレッジが向上します。 これらのレイヤーが連携することで、レジストリに記載されていないサービスの操作も含め、ほとんどの操作を動詞に基づいて分類できるように設計されています。レスポンス検証は、ルールが見落とした操作を検出するのに役立ちます。 リージョンごとのライブ料金 料金は AWS リージョンによって異なるため、基準料金を保持せず、見積もり時に AWS Price List API を使用して、ワークロードのリージョンの料金をリアルタイムで取得します。 リージョンはリソース ARN から取得されます。 各料金は pricing:GetProducts で検索され、ワークロードのリージョンを使って一致する料金が選択されます。 その結果、ワークロードが実行されるリージョンの現在の定価に基づくコスト見積もりが得られます。 クロスリージョンへの対応 対象リージョンが Agent Space のリージョンと異なる場合、スキルはデータ転送コストを追加します。特定の送信元から送信先までの経路に対応する料金をリアルタイムで取得し、経路ごとにキャッシュします。リージョン間の料金は地域によって大きく異なるため、一律の料金を仮定せず、その経路に対応する正確な料金を検索します。 判定ゲート 計画された呼び出しの分類、料金の取得、予算との照合が完了すると、ガードレールは次の 3 つの方法のいずれかで判定します。番号は、上の図 1 に示した結果に対応します。 Proceed（続行） ：見積もりが残りの予算内に収まっています。呼び出しは中断なく実行され、調査タイムラインにはステップごとの見積もりと累計額の両方が記録されます。 Warn（警告） ：呼び出しは予算内ですが、非効率の兆候が見られます。たとえば、広範な PromQL クエリ、単一サービスに対する 200 回以上の呼び出し、リージョン間の転送などです。ガードレールは呼び出しの実行を許可しつつ、時間枠の短縮、ラベルフィルター、ステップ間隔の拡大など、コスト効率の高い代替案を添えます。 Halt（停止） ：見積もりが残りの予算を超える場合、時間枠が指定されずにスキャンが要求された場合、またはライブ料金検索で料金を取得できなかった場合、呼び出しは実行されません。ガードレールは最悪ケースの見積もりを提示し、データをスキャンする前に指示を求めて一時停止します。 ガードレールが停止した場合は、必ず次に進むための方法を提案します。 正確なタイムスタンプ、またはより短い時間枠を指定する 特定の 1 つのサービスまたはロググループを対象にする 既知のエラーメッセージを指定する。これにより、エージェントは Logs Insights クエリの代わりに、GB 単位のスキャン料金が発生しない FilterLogEvents API で検索できる リージョン間の転送料金を避けるため、クエリを同一リージョンのソースに限定する シナリオ例 次のシナリオは、同じ決済ワークロードに対する 3 つのリクエストを示しています。いずれもエンジニアが DevOps Agent コンソールに入力したものです。課金対象の呼び出しを実行する前に、ガードレールは必ずライブ料金を取得し、コストを見積もり、調査ごとの予算 $10.00 と照合します。異なるのは結果だけです。見積もりは定価に基づいており、AWS 無料利用枠の適用分は含まれません。 シナリオ A：対象を絞り、時間枠を指定したリクエスト（続行） SRE は次のように依頼します。 「今日の 13:57～14:27 UTC に us-east-1 の payments-prod-alb で発生した 5xx エラーを調査してください」 30 分の時間枠が指定されているため、スキルは Amazon CloudWatch Logs Insights のスキャン量を算出できます。スキャン量は 1.34 GB で、ライブ料金は $0.005/GB なので、コストは $0.0067 です。$10.00 の予算内なので、クエリは実行され、調査が続行されます。 図 2：最初の課金対象呼び出し前にライブ料金、スキャン見積もり、予算チェックが実施され、その後、実際のコストを検証。実際のコストはリージョン、データ量、現在の料金によって異なります。 シナリオ B：1 か月分のデータを対象とする広範なリクエスト（停止して確認） クラウドアーキテクトは次のように依頼します。 「9 月全体の payments-api のすべての 5xx エラーと DynamoDB のスロットリングを相関分析してください」 スキャン対象は 2,673 GB、コストは $13.37 になるため、エージェントは開始前に停止し、料金付きの選択肢を提示します。追加の $3.37 を承認する、対象期間を 7 日間（$3.74）、24 時間（$0.54）、またはインシデントの時間枠（$0.007）に短縮する、データスキャン料金のないメトリクス相関を使用する、あるいはここで終了する、という選択肢です。この時点では、データは一切スキャンされていません。 図 3：エージェントは予算超過時に停止し、エンジニアが続行するための選択肢を料金付きで提示。実際のコストはリージョン、データ量、現在の料金によって異なります。 シナリオ C：有料スキャンを行わないよう指示したリクエスト（スキャン料金のない API に切り替え） DevOps エンジニアは次のように依頼します。 「02:45～03:15 UTC に payments-worker が payments-events-dlq へイベントを送信している理由を調べてください。今回は有料のスキャンを一切実行しないでください」 2 つの有料呼び出しについて料金が算出されます。ワーカーのロググループに対する Amazon CloudWatch Logs Insights クエリ（38.37 GB、$0.19）と、12 個のメトリクスを取得する GetMetricData バッチ（$0.004）です。どちらも予算内ですが、エンジニアが有料スキャンを除外したため、エージェントはデータスキャン料金のない代替手段に切り替えます。エラーが既知の文字列であるため FilterLogEvents を使用し、GetMetricData の代わりに、メトリクスを 1 つずつ取得する GetMetricStatistics を使用します。後者は AWS 無料利用枠の CloudWatch API リクエスト数に計上されます。その結果、checkout-api の新しいリリースによってイベントスキーマが変更されたことが判明しました。 図 4：予算内でもエンジニアの指示に従ってスキップし、Logs Insights クエリと GetMetricData バッチの代わりとなる、データスキャン料金のない呼び出しを表示。 より広いパターン：トークン予算からアクション予算へ このガードレールは、従量課金 API を呼び出す自律型 AI エージェントの設計パターンを示しています。エージェントは行動する前に、その行動にどれくらいの費用がかかるかを把握できます。 これは、AI エージェントの経済性を、トークン予算（推論のコスト）からアクション予算（実行のコスト）へと捉え直すものです。エージェントがツールへアクセスできる場合、真の価値が生まれるのは、エージェントが実行する下流のアクションです。その価値を事前に可視化することで、意図的かつ利用者が承認した予算へと変えることができます。 クラウドアーキテクトや SRE は、何年もかけてこの感覚を身につけます。コストガードレールにより、エージェントは初日からこの感覚を備え、一貫して適用します。午前 3 時のインシデント対応を含め、プレッシャーのかかる状況でも、この規律を維持できるように設計されています。 技術的な実装 このスキルは、コアエージェントを変更することなく、エージェントの既存のスキル階層へ組み込まれます。各調査の前に、次の手順で事前チェックとして実行されます。 エージェントによる探索結果（クエリを実行する予定のロググループ、メトリクス、トレース）を読み取る 計画された各操作を 4 つのレイヤーで分類する AWS Price List API からリージョンごとのライブ料金を取得する コストの完全な内訳とともに、構造化された判定（続行または一時停止）を返す 一時停止する場合は、スコープを絞るための具体的なガイダンスを提供する AWS DevOps Agent は、すべてのセッションに権限のガードレールを適用します。常時適用されるポリシーであるエージェントインストラクションと、オペレーターに明示的な承認を求めるダイレクテッドアクションを組み合わせることで、利用者が定義した境界内でエージェントを運用し続けることができます。 開始方法 Investigation Cost Guardrail は、AWS の GitHub 組織にあるオープンソースリポジトリ aws/tools-for-devops-agent で公開されており、AWS DevOps Agent サービスチームが管理しています。このリポジトリには、インポートしたり独自にカスタマイズしたりできる、コミュニティ作成のスキル、カスタムエージェント、MCP サーバーが含まれています。 前提条件 少なくとも 1 つの AWS アカウントが接続された AWS DevOps Agent の Agent Space Agent Space が引き受ける IAM ロールを更新する権限 手順 1：IAM 権限を付与する このスキルは、見積もり時に AWS Price List Query API を使用してすべての料金を取得します。接続されている各アカウントで、Agent Space が引き受ける IAM ロールに、次のポリシーをアタッチします。権限の詳細については、スキルの README にある Required IAM permissions を参照してください。 { "Version": "2012-10-17", "Statement": [ { "Sid": "ResolveLivePricing", "Effect": "Allow", "Action": "pricing:GetProducts", "Resource": "*" } ] } 手順 2：スキルをインストールする 次の 2 つの方法のいずれかで、スキルを Agent Space に追加します。 オプション A：GitHub 統合（チームに推奨） ： aws/tools-for-devops-agent をフォークするか、 skills/investigation-cost-guardrail/ ディレクトリを自分で管理するリポジトリにコピーし、Agent Space の GitHub 統合を通じてインポートします。これにより、スキルをバージョン管理下に置き、コミットを固定し、プルリクエストで SKILL.md の変更をレビューし、独自の検索パターンで references/pricing-reference.md を拡張できます。 オプション B：直接アップロード ：リポジトリからスキルを .zip としてダウンロードし、Agent Space コンソールでユーザー定義スキルとしてアップロードします。アーカイブでは、スキルディレクトリのルートに SKILL.md を置き、その隣に references/ フォルダーを配置する必要があります。 investigation-cost-guardrail/ ├── SKILL.md └── references/ └── pricing-reference.md 手順 3：スペースレベルの指示を追加する スキルは、説明とのマッチングに基づいてオンデマンドで読み込まれます。各調査でコストガードレールが読み込まれるようにするためには、Agent Space のインストラクションに次の内容を追加します。 “Before executing any tool call that interacts with AWS or third-party services, ALWAYS consult the cost guardrail skill to estimate cost and check budget. Never skip cost evaluation” 日本語訳：「AWS またはサードパーティーサービスとやり取りするツール呼び出しを実行する前に、コストの見積もりと予算の確認のため、必ずコストガードレールスキルを参照してください。コスト評価を決して省略しないでください」 これは、前述した 2 つの仕組みを組み合わせたものです。指示は常設命令であり、スキルはその命令によって呼び出される能力です。 手順 4：環境に合わせてしきい値を調整する このスキルには、調査ごとに $10.00 という保守的なデフォルト予算が設定されています。Agent Space の設定に自然言語の指示を追加するか、 SKILL.md ファイルを直接編集することで上書きできます。たとえば、「調査ごとの予算を $25.00 にしてください」と指定します。 スキルファイルを編集せずに、既知の有料操作レジストリを拡張したり、特定の操作に対する制御を強化したりすることもできます。 opensearch:Search を、1,000 リクエストあたり $0.01 の有料操作として扱う Athena クエリを実行する前に必ず承認を求める 手順 5：検証する ガードレールが有効であることを確認するため、2 つの調査を実行します。 最初に、データ量の多いロググループに対して時間枠を指定せず、たとえば「order-service のエラーを調査してください」という調査を開始します。エージェントは logs:StartQuery を実行する前に停止し、ロググループに保持されている全データ量から算出した最悪ケースの見積もりを提示し、時間枠または既知のエラー文字列を求めるはずです。 次に、時間枠を限定して繰り返します。「今日の 14:00～14:30 UTC に order-service で発生したエラーを調査してください」と入力します。調査タイムラインには、最初の課金対象呼び出しの前に予算ステータスブロックが表示され、各料金には、その料金がどのリージョン向けに取得されたかが明記され、調査が続行されるはずです。 COST CHECK Budget: $10.00 | Spent: $0.00000 | Next: 1 × logs:StartQuery (6.4 GB × $0.005/GB) → $0.03200 | Projected: $0.03200 WITHIN BUDGET Proceeding 最初の調査が一時停止せずに進んだ場合は、手順 3 のスペースレベルの指示が存在することを確認してください。2 つ目の調査が料金取得エラーで停止した場合は、 pricing:GetProducts のアクセス許可とツールポリシーにおける us-east-1 の許可を再確認してください。 クリーンアップ ガードレールと、それを支える設定を削除するには、セットアップ手順を元に戻します。 手順 3 で追加したスペースレベルの指示を Agent Space の指示から削除する Agent Space が引き受ける IAM ロールから、 pricing:GetProducts のインラインポリシー（および追加した読み取り専用のサイジングポリシー）を削除する Agent Space から Investigation Cost Guardrail スキルを削除する まとめ AWS DevOps Agent は自律的なイベント対応を実現します。その自律性にコスト意識を加えることで、チームは運用成熟度の次の段階へ進むことができます。つまり、利用者が定義した透明性のある予算内でインシデントを迅速に解決できます。 Investigation Cost Guardrail は、経験豊富なエンジニアが本能的に理解している原則、すなわち実行前にコストを評価するという原則を適用します。サービスを横断して操作を分類し、AWS Price List API からリージョンごとの現在の料金を取得して、調査コストを透明性があり、利用者が管理できる予算へと変えます。エージェントの速度を低下させるものではありません。エージェントにコスト判断力を与えるものです。 開始するには、GitHub の tools-for-devops-agent から Investigation Cost Guardrail スキルをクローンし、AWS DevOps Agent の設定に追加して、調査にコストを意識した事前チェックを導入してください。 新しいコスト分類や料金パターンについてアイデアがありますか。このガードレールは自由に拡張できます。 investigation-cost-guardrail をフォークし、チームが最も頻繁に実行する操作を追加して、独自の料金モデルを参照するようにしてください。構築したものを共有するには、Issue を作成するか、プルリクエストを送信してください。 Ines Attia Ines は AWS のテクニカルアカウントマネージャーです。エンタープライズのお客様と協力し、スケーラブルでレジリエントかつ Well-Architected なワークロードを設計しています。クラウドアーキテクチャに関する専門知識を生かし、オブザーバビリティと AIOps を運用上の優秀性の向上に適用し、技術上の選択をビジネス成果へ結び付けています。 Tipu Qureshi Tipu は AWS のシニアプリンシパルエンジニアで、DevSecOps 向けエージェンティック AI システムのフルスタック設計と実装を率いています。最先端の AI モデル、専門スキル、MCP ツールを活用する自律型エージェントを構築し、クラウド運用、開発者ワークフロー、カスタマーサポートを変革しています。15 年以上にわたり、運用上の優秀性への情熱を持って、多様な分散システムを大規模に設計、運用、構築してきました。 本ブログは、2026 年 10 月 6 日に公開された「 Control investigation costs before they start with AWS DevOps Agent 」の日本語訳です。翻訳はテクニカルアカウントマネージャーの日平が行いました。

こんにちは。ファインディ株式会社のプロダクトマネジメント室GenAI Enablementチームで、社内のデータ・AI活用を推進している山家です。 2026年10月5日（月）に、CTO室データソリューションチームとプロダクトマネジメント室GenAI Enablementチームの共催で、採用イベント 「ファインディにおけるデータ活用とAIがもたらす現場変革のリアル」 を、ファインディ本社でオフライン開催しました。 findy-inc.connpass.com この記事では、イベントを企画した背景と当日の4本のセッションを、参加できなかった方にもイメージが伝わるようにまとめます。あわせて、それぞれのチームが抱える課題と今後についても紹介します。 イベント開催の背景 データソリューションチーム セッション1: AIエージェントのためのデータ品質Ops セッション2: 2025年に事業部化したプラットフォーム事業部でのデータ活用 現在とこれから データソリューションチームの今後 GenAI Enablementチーム セッション3: データ問い合わせエージェントと求人推薦システムから見る、当社のデータ活用事例 セッション4: 領収書OCRを作ったら、OCR以外の仕事が本体だった GenAI Enablementチームの今後 まとめ イベント開催の背景 ファインディでは事業の広がりとともに、データ基盤やデータモデリングを整える仕事と、生成AIで現場の業務そのものを変える仕事の両方が進んでいます。データソリューションチームは全社の共通データ基盤とその品質を、GenAI Enablementチームは現場の業務にAIを届けることを担っています。 2つのチームは所属組織は違えど、密接に関係しています。AIが適切に動作するにはデータの品質が欠かせず、AIやデータを現場で使ってもらうには業務への埋め込みの設計が欠かせません。今回のイベントを、両チームがどのような課題に向き合い、どのように取り組んでいるかをお話しする機会にしました。 セッションは4本立てで、データソリューションチームとGenAI Enablementチームが2本ずつお話ししました。 データソリューションチーム データソリューションチームからは、AIエージェントに向けたデータ品質の運用と、新設事業部でのデータ活用の立ち上げについてお話ししました。 セッション1: AIエージェントのためのデータ品質Ops 登壇者: 田頭 speakerdeck.com AIエージェントにデータを使わせるために、dbtモデルの品質をどう運用しているかを紹介しました。データの使われ方は、人がLookerやSQLで集計する形から、AIエージェントに質問する形へ変わってきています。そのなかで、利用者側ではどのモデルを使えばよいかをエージェントに伝えられないという課題がありました。運用側でも、重要なモデルと検証用のモデルが同列に扱われ、ビルドが失敗したときにすぐ対応すべきか判断できませんでした。 そこで、dbtモデルを、算出する数値の用途で4段階のTierに分けました。テストやdescriptionといった品質要件は、工数のかかるものほど上位のTierに限定して求め、Tier 4だけはAIエージェントに使わせません。各Tierの用途と品質要件は次のとおりです。 Tier 用途 テスト description テスト失敗時の対応 AIエージェントの利用 Tier 1 外部公表数値・KPIの決定 主キー・外部キー・整合性 全カラムと計算ロジック 当日対応 可 Tier 2 部門の意思決定・定常レポート 主キー・主要な外部キー キー・指標カラム 週次で確認 可 Tier 3 部門オペレーション・データ抽出 主キー（推奨） モデルのみ ベストエフォート 可 Tier 4 アドホック・個人検証 要件なし 要件なし 要件なし 不可 Tier 1の起点の選び方では、AIと人の役割を分けています。LookerとBigQueryのクエリ履歴からClaude Codeのスキルが候補を出し、KPIに実際に使われているかはデータエンジニアが事業部に確認して決めます。確定した起点から dbt ls --select +<起点> で上流のモデルを列挙し、Tier 1を確定します。 現状、Tierはデータエンジニアの運用ルールとして使われている段階で、AIエージェントがTierを参照する仕組みはまだありません。今後は計算ロジックや用語集をKnowledge Catalogに集め、AIエージェントがTierの高いモデルと必要なコンテキストを取得して分析できる形を目指しています。 セッション2: 2025年に事業部化したプラットフォーム事業部でのデータ活用 現在とこれから 登壇者: 出相 speakerdeck.com 2025年に発足したプラットフォーム事業部で、データ活用をゼロから立ち上げている取り組みを紹介しました。発足当初は事業部付きのアナリストがおらず、事業部向けにデータを見る基盤もない状態でした。 最初に取り組んだのは、身近でデータに困っていると話していたカンファレンス集客の担当者の作業です。開催のたびに、業務に必要な対象リストを手作業で抽出し（1回約15分）、重複を関数で確認する（約30分）作業がありました。今後も開催数の増加が見込まれる中、これらの作業負荷がさらに高まることが課題でした。そこで、ヒアリングで必要なデータを把握し、BigQueryの共通基盤に集約、dbtでモデル化、Lookerで可視化するまでを一気通貫で整備しました。担当者へのヒアリングによると、リスト抽出にかかる時間は2〜3分に短縮され、重複率はダッシュボードで一目で分かるようになりました。 この1人との定例を起点に、困りごとを聞き、データを揃え、効果を見せ、その担当者の紹介で次の担当者へつなぐという循環を回して、事業部全体へ広げています。基盤の全体設計から入るのではなく、1つの業務を解いて次の相談を引き出す進め方です。 一方で、整えたデータが使われないという課題や、社内でNotionの活用が進みはじめるという状況の変化も出てきました。今後はNotionを入口に、Lookerのセマンティックレイヤーや共通データ基盤へたどれる状態を目指し、メタデータ・導線・定義の整備に取り組んでいきます。 データソリューションチームの今後 データソリューションチームが目指すのは、経営から現場まで、同じ正しい数字で意思決定できる状態です。共通データ基盤を作るだけで終わらせず、その数字が何を意味し、どこから来たのかを説明できるところまでを自分たちの仕事と考えています。 そのためにまず、指標を説明できる状態にします。KPIが何を表し、どのように計算されているのかを誰でも確かめられるようにします。そのうえで、数字が正しいことを前提に、予算と実績のズレを早く見つけられるようにします。ズレに気づいた人やAIが、すぐ次のアクションに移れる状態を目指しています。 Tierは運用ルールとして使われ始めた段階です。定期的な見直しや、計算ロジック・用語集をKnowledge Catalogへ集める取り組みはこれからです。AIエージェントが正しいデータを参照できるかを実際の問いで確かめながら、メタデータを育てていきます。 並行して、GenAI Enablementチームと協力しながら、AX（AIが業務を進め、人が要所で判断する形への業務の作り直し）と、データ基盤のセルフサービス化を進めています。AIや人が自分の手で課題を解決できるようなデータ基盤を目指していきます。 少数精鋭のチームなので、単発の作業で終わらせず、自動化や型化で横に広げられる仕組みにすることを大切にしています。経営と事業の意思決定に直結するデータ基盤を一緒に育てていけるデータエンジニアを募集しています。 GenAI Enablementチーム GenAI Enablementチームからは、社内向けの求人推薦と経費処理を例に、現場の業務にAIを組み込む取り組みをお話ししました。 セッション3: データ問い合わせエージェントと求人推薦システムから見る、当社のデータ活用事例 登壇者: 山家 speakerdeck.com 社内向けの求人推薦システムを例に、作った仕組みが現場で使われるための置き方を紹介しました。当日は時間の都合でお話しできませんでしたが、社内のデータ問い合わせに答えるエージェントを作った事例も登壇資料に載せているので、あわせてご覧ください。 転職事業では、ユーザーサクセス（US）が面談後に求人を紹介しています。担当者は紹介する求人を記憶と経験をたどって探しており、掲載求人が増えるほど追いつかなくなっていました。そこで、候補者ごとの推薦求人リストを出す仕組みを作りました。仕組みは次の図のとおりです。 求人票とUS面談メモをEmbeddingでベクトル化し、類似度で求人を並べたうえでフィルタをかけています。全体をBigQuery上のバッチで回しており、手法自体はシンプルなものにしています。 業務への導入方法はかなり意識をしました。以前作った検索系機能は現場の業務フローの外にあり、使われませんでした。そこで推薦では、面談メモを書いた後、紹介する求人を選ぶタイミングで、USが普段使うSalesforce上に観点ごとに分けて求人を出しました。推薦が引き受けるのは探す手間だけで、選んで紹介するのはUSのままです。その結果、USへのアンケートでは求人探索の工数が40%弱削減され、推薦経由の紹介も毎日生まれています。 ただし、使われることは成功と同じではありません。紹介求人の多くはカスタマーサクセス（CS）経由で、推薦が速くしたのはUSが自分で探す部分だけでした。現在は事業部全体にヒアリングし、事業のあるべき姿から逆算して、どのように業務を自動化していくかを計画しています。 セッション4: 領収書OCRを作ったら、OCR以外の仕事が本体だった 登壇者: 奥田 speakerdeck.com 秘書チームの経費処理を、生成AIでどう改善したかを紹介しました。月約160枚の領収書について、日付から予定を探し、参加者とその属性を確認し、経費区分を考えてSaaSへ転記する作業がありました。OCRで日付や金額を読み取れても、判断材料はカレンダー・組織図・人事情報に分かれたままです。 そこで、処理ごとに担い手を分けました。GASがSlackに投稿された領収書を取得し、Geminiが画像の読み取りと予定候補の選択を担います。参加者はGoogleカレンダーから、部門・役職・入社日は社員情報APIから取得し、決まった条件はコードで適用します。兼務は複数部門として扱い、入社日が取れなければその情報が必要な判定はしません。最後は秘書チームが判定理由と予算の利用状況を確認して区分を確定します。秘書チームの概算では、確認作業が月160分削減されました。 エラーの扱いも見直しました。判定できた、判断材料が足りない、取得処理に失敗した、の3つを分けて残し、情報不足なら人への確認、取得失敗なら再実行や調査へ進めるようにしています。 GenAI Enablementチームの今後 GenAI Enablementチームは、現場へのヒアリングから、社内データの接続、人が確認できる運用づくりまでを一気通貫で担います。 今は事業部全体の業務フローを、AIが主体で進め、人が要所で判断する形へ再設計しています。まずは担当者がAIの提案を確認・修正して使います。その記録で徐々にAIの精度を上げながら、AIに任せる範囲を広げていきます。 そのために欠かせないのが、データPdMとデータサイエンティストです。データPdMは、業務の中でどんなデータを生み、売上につなげるかを事業部と決めます。データサイエンティストは、今のやり方とAIを比べて効果を測り、任せる範囲を広げる根拠をつくります。事業責任者やPdMと会話しながら、データと実装を行き来して価値を届けたい方を募集しています。 まとめ 今回のイベントでは、データ品質の運用から、新設事業部でのデータ活用の立ち上げ、現場業務へのAIの組み込みまで、4名の視点からお話ししました。どのセッションにも共通していたのは、技術そのものよりも、データやAIを業務のどこにどうつなぐかを軸に進めてきたことです。仕組みは作るだけでは使われず、品質の優先度付けや業務フローへの埋め込み、人が確認できる運用まで設計して初めて現場が変わると考えています。 セッション後の懇親会でも、登壇では話しきれなかった失敗談を含め、参加者の皆さんと実務の話で盛り上がりました。こうした話ができるのは、オフライン開催ならではだと感じています。 参加してくださった皆さん、ありがとうございました！ ファインディでは、データとAIの力で現場を変えていく仲間を募集しています。今回のイベント内容に少しでも興味を持っていただけた方は、ぜひお気軽にカジュアル面談などでお話ししましょう。 データソリューションチームの求人はこちら。 herp.careers GenAI Enablementチームの求人はこちら。 herp.careers herp.careers

こんにちは。ファインディ株式会社でFindy Team+の開発をしているkameです。 経歴としては、異業種から転職して現在エンジニア2年目です。ファインディには2026年5月に入社し、5ヶ月ほどが経過しました。 ファインディでは設計、実装、レビューなど各プロセスにおいてAIを活用しています。 このような経歴、環境下での私自身の思考の変化や、取り組んできたことに関して紹介します。 入社直後に感じたことから、事業に貢献したいと考えるようになるまで AIを活用して設計・実装するには、基礎力が必要だと実感した 基礎力強化が推奨される環境下で、勉強会に参加 個人学習として取り組んだこと 基礎力の強化が、普段の設計・実装にどのように生きてきたか ジュニアエンジニアの成長を支えてくれる会社のカルチャー 定期的な1on1や勉強会を通じて、自分の中の不明点を整理できる 基礎力強化を応援する文化 まとめ 入社直後に感じたことから、事業に貢献したいと考えるようになるまで 入社直後は、実装経験をたくさん積んで、エンジニアとしての技術力を高めたいという気持ちが第一にありました。 実際に、入社2日目から技術改善系のタスクにアサインしていただきました。プロダクトのドメインを理解しながら技術面の知見も深められる、良い環境だと感じています。 実際のアクティビティの推移を見ても、入社後から少しずつ伸ばしてこられたと感じています。(各棒グラフは上からイシュー作成数、プルリク作成数、マージ済みプルリク数、コミット数、レビュー数) 入社して1ヶ月半が経ったタイミングで、期の変わり目にAI時代の開発組織を模索する新しいチームが立ち上がり、そこにジョインすることになりました。 このチームでは、事業部メンバーからの声や顧客の声を直接聞き、エンジニアが要望のヒアリングから企画、実装、リリースまで一貫して行っています。このチームにアサインされたことをきっかけに、事業貢献の意識が強くなりました。 タスクとしては、社内のカスタマーサクセスから上がってきた要望を受け取り、Issueに落とし込んで実装まで行う機会が増えました。 直近ではFindy Team+のMCPサーバーを中心に開発しています。MCPツールの追加や関連するAPIの開発だけでなく、MCPツールの効果を追跡できるログや集計の基盤を作ったり、カスタマーサクセスと一緒にプロンプト例を考えたりしています。 この過程では、初めて実務で使う言語のキャッチアップを個人で進めたり、レビューを通してより良い書き方を学んだりしました。また、MCPサーバーは画面上に見える機能ではないため、実際に自分でプロンプトを試し、他の人からもフィードバックをもらいながら、どのような出力が出れば利用者に価値を感じてもらえるかを調整する難しさも経験しました。 ビジネスサイドと連携しながらタスクを進める過程を経験する中で、個人の技術的な知見を深めるだけでなく、事業に貢献できる状態を目指したいと思うようになりました。 AIを活用して設計・実装するには、基礎力が必要だと実感した しかし、AIを活用して設計、実装する上では、課題を感じることがありました。AIの出力する情報に理解の足りない単語が多く、AIが何を言っているのか調べるだけで、時間がどんどん過ぎてしまうこともありました。具体的には、次のような場面です。 問い合わせ起因で通信周りを調べる必要があった際に、「トランスポート層で処理される」という話が出ても、TCP/IPモデルの知識が乏しいため、何が行われているかのイメージがつかなかった パフォーマンスを考慮する必要があった際に、アルゴリズムのパターンの知識が足りていないため、既存のコードを参照して書かれたAIのコードに対して、「より良い書き方はないか？」という疑いの目を持つことができなかった また、AIとの壁打ち以前に、Issueを読み解く段階で苦労することもありました。例えばデータベース関連のIssueでは、ACID特性に関連する用語を理解しきれておらず、AIに解説してもらう必要がありました。 これらの課題は、実装以前に、コンピューターサイエンスの基礎知識が不足していたことからきていました。 このままではAI前提の開発のスピードについていけなくなる、という危機感を持ち、基礎知識を固めたいという気持ちが強くなりました。 基礎力強化が推奨される環境下で、勉強会に参加 ファインディでは、コンピューターサイエンスの基礎力強化のために、基本情報技術者試験レベルの知識習得がエンジニア全員に求められています。 そうした中で、有志によって開催されていた週1回の勉強会に誘っていただき、コンピューターサイエンスの基礎知識を学習するようになりました。 勉強会では、基本情報技術者試験の科目Aの過去問を実際に解き、シニアエンジニアの方から「どのような場面で役に立つ知識か」を説明いただきながら解答を理解していきました。 印象に残っているのは、リエントラント（再入可能）に関する問題を扱った回です。例えばRubyでは、変数が外部から書き換えられないようにローカル変数を使うといった考慮を行う、という話を聞き、安全なプログラムを書く上で覚えておくべき概念だと感じました。 これまで、資格勉強が普段の業務にどう役立つのかはイメージがつきませんでした。業務を進める上での土台となる知識だと自分の中に落とし込めたのは、勉強会に参加して良かったと思う点の1つです。 個人学習として取り組んだこと 基本情報技術者試験に合格する上では、過去問のテキストを購入して、本番の時間内に解けるまで周回しました。 今回は合格自体が目的ではなく「基礎力の強化」を行いたかったので、追加で次の点を意識しながら学習に取り組みました。 選択問題に関しては、正解以外の選択肢に関しても理解を深める 正解以外の選択肢は、別の基礎的な用語に関する説明であることも多いため 問題と実務の記憶が紐づく場合は、その場面をノートにメモしながら解説を読む 実際の実務に結びつけて理解した方が、同様の場面に遭遇したときに知識が生きるため 結果として、基本情報技術者試験に合格することができました。 基礎力の強化が、普段の設計・実装にどのように生きてきたか まだまだ足りていない基礎知識が多いという感覚はありつつも、コンピューターサイエンスの知識が全くなかった状態から知識を身につけると、次のような実感がありました。 設計や実装の壁打ちをする際に、AIの出力する内容で理解できる単語が増えた分、以前と比べてやりとりがスムーズになった 既存コードを読む際に、「どのようなアルゴリズムのパターンで書かれているか」を意識し、「別のパターンで書いたら計算量はどうなるか」という観点でAIと壁打ちするようになった 問い合わせや社内の会話の中で、AIに聞かなくても理解できる概念が増えた 例）IPアドレスとサブネットマスクから利用可能なホスト数を求める方法を理解したことで、普段の業務でよく目にするIPアドレスの許可範囲がどのように決められているのかをイメージできるようになった 難易度の高い設計や実装に取り組む際に、知らない概念が多いことに気付かされ、さらなる基礎力強化の必要性を感じるようになった 例）難易度が上がるほどAIも複数のパターンから人間に判断を求めてくることが多く、その中から根拠を持って「このパターンが良い」と答えるには、さらにベースとなる知識のストックを増やしていく必要があると感じた AIといくらでも壁打ちできる環境にいるからこそ、自分の中にある前提の基礎知識をもとにどの出力を採用するべきかを判断する力は、重要であると実感しました。 ジュニアエンジニアの成長を支えてくれる会社のカルチャー ファインディには、歴の浅いエンジニアの成長を支えてくれる仕組みと雰囲気があります。具体的には次のようなものです。 定期的な1on1や勉強会を通じて、自分の中の不明点を整理できる 各々の関心に合わせ、シニアエンジニアの方が勉強会を開いてくれる場面が多くあります。内容は基本情報技術者試験に向けた勉強会やアルゴリズムの解説など様々です。 また、社内全体で1on1が活発に行われており、話を聞いてみたい人に1on1を依頼すると、快く引き受けてくれる雰囲気があります。 技術的な内容は他のエンジニアに、ビジネスサイドの知見が足りていないと感じるときは営業の方に質問するなど、部署を超えた連携が活発に行われています。 そのような環境のおかげで、社歴やエンジニア歴が浅かったとしても心理的ハードルを感じずに他の人から知見を集めることができます。 結果として、技術的知見・ビジネス的知見双方への関心が強くなり、さらに理解を深めていきたいという意欲につながっていると感じています。 基礎力強化を応援する文化 AIがコードを出力してくれる時代だからこそ、ベースとなるコンピューターサイエンスの基礎知識が必要、という考え方を、普段の業務で活躍しているシニアエンジニアの方を中心に浸透させてくれています。 そのため、基本情報技術者試験の合格に向けて勉強しているエンジニアやコンピューターサイエンスの知識を学習するエンジニアを応援し、資格試験に合格したら労ってくれる雰囲気があります。 また、資格試験合格のためにナレッジを共有したり、受験や学習を通して学んだことを社内アウトプットとして共有する人も多いです。自分はそのおかげで良い刺激を受け、学習を続けるモチベーションになりました。 こうした雰囲気は、ファインディのバリューの1つである「前向き」が組織に浸透していることの表れだと感じています。 まとめ 今回は、エンジニア2年目の自分の、次のような思考の変化に触れました。 ビジネスサイドとの連携が増える中で、事業部へ貢献したいという気持ちが強まる AIを活用して設計・実装を進める中で、AIの出力やIssueを理解するための基礎力が不足していると実感 社内勉強会や個人学習を通じて基本情報技術者試験に合格し、コンピューターサイエンスの基礎的な理解を深める そういった基礎理解が、実務にも生きるようになった AIがコーディング業務を担う時代に、どのような力を伸ばせば良いか迷っていました。そんな時にコンピューターサイエンスの基礎の重要性を教えていただいたシニアエンジニアの方々と、学習を前向きに応援してくれた会社のカルチャーのおかげで、このような思考の変化が起きたと思っています。 今回は基本情報技術者試験合格に向けた学習をメインで行っていましたが、現在は基本情報技術者試験の問題の中で難しいと感じた分野・苦手だと感じた分野に関して個別の技術書を読んで理解を深めています。 今後も各分野の基礎理解を深めて日々の設計・実装に活かし、事業に貢献できるエンジニアを目指していきたいと思っています。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers