本記事は 2026 年 2 月 26 日 に公開された「 Amazon OpenSearch Serverless introduces collection groups to optimize cost for multi-tenant workloads 」を翻訳したものです。 本日、Amazon OpenSearch Serverless のコレクショングループ機能の一般提供を開始しました。テナントごとの暗号化による安全なテナント境界を維持しながら、マルチテナントワークロードのコンピューティングコストを削減できます。コスト効率とアプリケーションに必要な分離・セキュリティレベルを柔軟に調整できます。 Amazon OpenSearch Serverless は Amazon OpenSearch Service のサーバーレスデプロイオプションで、検索や分析ワークロードを大規模に実行する際のインフラストラクチャ管理が不要になります。使用パターンが変化しても、リソースを自動的にプロビジョニング・スケーリングし、高速なデータ取り込みとミリ秒単位のレスポンスタイムを実現します。マルチテナント環境を管理する組織にとって、テナントのデータを暗号化して保護するデータ分離 (多くの場合、独自の暗号化キーを使用) はコンプライアンス要件です。 従来、OpenSearch Serverless は物理的な分離で高いセキュリティを確保していました。各 AWS Key Management Service キー (KMS キー) には、完全な物理的データ分離を維持するための専用 OpenSearch Compute Units (OCU) が必要でした。このアーキテクチャは高い保護を提供する一方、大規模なマルチテナントデプロイでは課題がありました。共有暗号化キーを使用する複数テナントの場合、OCU リソースは効率的にプールされ、経済性は良好です。しかし、データ分離のために独自の KMS キーを必要とする小規模テナントを多数管理する場合、コストが高くなるという課題がありました。一意のキーごとに専用 OCU リソースが必要なため、個々のテナントが OCU 容量のごく一部しか使用しない場合、インフラストラクチャコストが過大になる可能性がありました。特に、顧客に Bring Your Own Key (BYOK) 機能を提供したいサービスプロバイダーに影響し、持続不可能なコストを負担するか、サービス提供を制限するかの選択を迫られていました。 OpenSearch Serverless は、コスト管理のための最大 OCU 設定による柔軟なキャパシティ管理を提供してきました。ほとんどのワークロードでは、需要に応じてキャパシティがスケールアップ・ダウンするため、使用した分だけ支払えば済みます。しかし、一部のワークロードパターンでは、最初から一定のベースラインコンピューティングを確保しておく方が適しています。突発的なトラフィックスパイク、高速データ取り込みパイプライン、負荷テストなどのシナリオでは、キャパシティを事前に割り当てておくことで、最初のリクエストから他のリクエストと同じ応答性で処理できます。同様に、マルチテナントアーキテクチャや時間的制約のあるオペレーションでは、コレクションがアクティブになった瞬間から予測可能で一貫したパフォーマンスが求められます。 コレクショングループによる柔軟な制御 コレクショングループにより、セキュリティ境界とリソース割り当てを柔軟に制御できます。画一的なアプローチではなく、セキュリティ要件とコスト要件に合わせてアーキテクチャを調整できます。仕組みは次のとおりです。 ニーズに合ったセキュリティ境界の定義 : コレクショングループは、関連するコレクションの論理的なセキュリティ構成です。各コレクショングループは、他のコレクショングループとメモリ、CPU、ディスクが物理的に分離されており、異なるセキュリティ構成間の強固なセキュリティ境界を確保します。 暗号化キー間でのリソース共有 : KMS キーの共有・個別使用に関係なく、コレクションをコレクショングループに割り当てられます。異なる暗号化キーを持つコレクションが同じセキュリティ境界内で OCU リソースを共有できるようになり、各テナントの完全な暗号化保護と論理的分離を維持しながら、コストを大幅に削減できます。 柔軟なネットワークアクセスでのデプロイ : コレクショングループは異なるネットワークアクセスタイプのコレクションをサポートし、パブリックエンドポイントと VPC エンドポイントのコレクションを同じグループ内に組み合わせられます。セキュリティと接続要件に合わせながら、グループ内の全コレクションで共有リソース管理のメリットを享受できます。 コストとパフォーマンスの制御 : 最大 OCU で支出を制限し、最小 OCU でベースラインパフォーマンスを保証します。二重制御により各コレクショングループのリソース範囲が明確になり、予期しないコスト増加を防ぎつつ一貫したパフォーマンスを確保できます。 インサイトによる最適化 : コレクショングループ全体のリソース消費、相対的な使用パターン、レイテンシーを示す詳細な CloudWatch メトリクスにアクセスできます。インサイトを活用して、割り当ての適正化、最適化の機会の特定、実際のワークロード動作に基づくパフォーマンスチューニングが可能です。 コレクショングループにより、最小・最大 OCU 設定の両方でリソース割り当てを完全に制御できます。 最大 OCU: コスト制御 リソースの上限を設定して、コレクショングループごとの過剰なスケーリングを防ぎ、コストを制御します。予期しないトラフィックスパイク時でも予算を超えないようにできます。コレクショングループのキャパシティ制限はアカウントレベルの制限とは独立して動作します。アカウントレベルの最大 OCU 設定はコレクショングループに関連付けられていないコレクションにのみ適用され、コレクショングループの最大 OCU 設定はそのグループ内のコレクションに適用されます。(全コレクショングループの最大 OCU の合計 + アカウントレベルの最大 OCU 設定) がアカウントの Service Quota で許可された最大 OCU 以下である必要があります。アカウントレベルとコレクショングループレベルの分離により、異なるセキュリティコンテキスト間できめ細かなコスト制御が可能です。 最小 OCU: パフォーマンス保証 コレクショングループに常に割り当てるベースラインコンピューティングリソースを定義し、一貫したパフォーマンスとリソースの可用性を確保します。OCU はコレクショングループ専用に予約され、次のメリットがあります。 コールドスタートなしの即時利用 : コレクションはスケーリング遅延なしで即座に利用できます。リソースは常にウォーム状態で準備されており、トラフィック到着時の遅延がありません。 キャパシティの保証 : 低アクティビティ期間中や他のコレクショングループとの競合時でもリソースが常に利用可能で、低トラフィック時でも予測可能なパフォーマンスを確保します。 予測可能なコスト : 最小 OCU は継続的に課金され、予測可能な請求と引き換えに予約キャパシティを提供します。保証されたパフォーマンスと引き換えにコストの確実性が得られます。予約ベースラインはオートスケーリングの基盤となり、需要の増加に応じて最大制限までキャパシティを拡張します。 最小・最大 OCU の組み合わせにより、要件に基づいてコスト最適化とパフォーマンス保証を柔軟に調整できます。 コレクショングループによるマルチテナントのコスト経済性 マルチテナントアーキテクチャのコスト管理では、分離、パフォーマンス、効率のバランスが常に求められ、いずれかを犠牲にすることが多くありました。コレクショングループは、セキュリティ境界を犠牲にすることなくコレクション間で共有キャパシティを実現し、従来の前提を覆します。コレクショングループの有無による違いを以下に示します。 コレクショングループ導入前 : データ分離のためにそれぞれ独自の KMS キーを必要とする 10 テナントの顧客を考えます。テナントのほとんどは控えめなデータ要件で、通常 10〜100 GB、大半はその範囲の小さい方です。実際のキャパシティニーズに関係なく、各テナントの暗号化キーに専用リソースを管理することで、大規模な運用の複雑さとコストの課題が生じていました。 コレクショングループ導入後 : 同じ顧客が、類似のセキュリティ要件を持つテナントをコレクショングループにまとめ、コレクション間で OCU リソースを共有できます。OCU キャパシティのごく一部しか必要としないテナントに専用リソースを割り当てる必要がなくなり、小規模テナントが多いワークロードではコストを最大 90% 削減できます。 最小 OCU 設定の場合 : プレミアムテナントは最小 OCU を設定したコレクショングループに配置してパフォーマンスを保証し、スタンダードテナントはより低い最小しきい値のコレクショングループでコスト効率を高められます。 次の表は、コレクショングループの有無で異なるテナント構成におけるインフラストラクチャコストを比較し、さまざまなデータサイズとクエリ負荷でのコスト削減効果を示しています。 一意の KMS キーを持つテナント数 データサイズとクエリパラメータ 完全なデータ分離のコスト (コレクショングループなし) コレクショングループ使用時のコスト 補足 10 データサイズ: 60 GB 以下 クエリ: ベース OCU (冗長コレクションの場合 1) を超えるコンピューティングが不要 $3,500 $350 コストを 10 分の 1 に削減。 10 データサイズ: 60 GB 以下 クエリ: ピーク時にベース OCU (冗長コレクションの場合 1) を超えるコンピューティングが必要 (例: コレクショングループなしではテナントあたり追加 5 OCU、コレクショングループでは共有インフラのメリットにより全テナントで 40 OCU)。 $3,500 + ピーク時のテナントごとのスケールアウト ($8,650) $350 + ピーク時のスケールアウト ($6,912) 追加のクエリ負荷がかかるとシステムがスケールアップし、追加 OCU がデプロイされます。負荷が減少するとシステムはベース OCU にスケールインします。 10 テナントごとのサンプルデータサイズ (GB): [3, 5, 7, 8, 10, 15, 18, 25, 28, 150] クエリ: データサイズに対する最小 OCU で一定レベルまでクエリを処理し、負荷に応じてスケールアウト。 サンプルデータサイズの場合、最小 OCU 要件は [2, 2, 2, 2, 2, 2, 2, 2, 2, 8] = 26 OCU [$4,492] + ピーク時のテナントごとのスケールアウト 最小コストは全テナントのデータを保持するために必要な OCU 数 (OCU あたり 120 GB × 2) + ピーク時のスケールアウトで決まります。サンプルデータサイズの場合、8 OCU [$1,382] + ピーク時のテナントごとのスケールアウト 追加のクエリ負荷がかかるとシステムがスケールアップし、追加 OCU がデプロイされます。負荷が減少するとシステムはデータを保持するために必要な最小 OCU 数にスケールインします。 注: 上記の計算は 冗長性が有効 なコレクションを前提としています。非冗長モードの場合、上記の計算の半分になります。 コレクショングループの使用開始 コレクショングループと最小 OCU 設定は、 OpenSearch Serverless が提供されている全 AWS リージョン で追加料金なしで利用できます。コレクショングループを作成し、新しいコレクションをグループに直接追加して管理を強化できます。既存のコレクションはコレクショングループとは独立して変更なく動作し続けますが、新しいコレクションでコレクショングループをすぐに使い始められます。 現在、新しく作成したコレクションのみコレクショングループに関連付けることができ、グループ内の全コレクションは同じタイプ (検索、時系列、またはベクトル検索) である必要があります。既存のコレクションは現在のキャパシティ管理設定で独立して動作し続け、1 つのコレクショングループ内に異なるコレクションタイプを混在させることはできません。AWS マネジメントコンソール、AWS CLI、AWS CloudFormation、または AWS CDK でコレクショングループを作成できます。次のセクションでは、OpenSearch Service コンソールでの作成方法を説明します。 最初のコレクショングループを作成するには: OpenSearch Service コンソール を開きます。 左のナビゲーションペインで Serverless を選択し、 Collection groups を選択します。 Create collection groups を選択します。 collection groups name にコレクショングループの名前を入力します。名前は 3〜32 文字で、小文字で始まり、小文字、数字、ハイフンのみ使用できます。 (オプション) Description にコレクショングループの説明を入力します。 Capacity management セクションで OCU 制限を設定します。 Maximum indexing capacity – グループ内のコレクションがスケールアップできるインデキシング OCU の最大数。 Maximum search capacity – グループ内のコレクションがスケールアップできる検索 OCU の最大数。 Minimum indexing capacity – 一貫したパフォーマンスを維持するためのインデキシング OCU の最小数。 Minimum search capacity – 一貫したパフォーマンスを維持するための検索 OCU の最小数。 (オプション) Tags セクションで、コレクショングループの整理と識別に役立つタグを追加します。 Create collection groups を選択します。 コレクションをコレクショングループに割り当てるには Amazon OpenSearch Service コンソール を開きます。 左のナビゲーションペインで Serverless を選択し、 Collections を選択します。 Create collection を選択します。 Collection name にコレクションの名前を入力します。名前は 3〜28 文字で、小文字で始まり、小文字、数字、ハイフンのみ使用できます。 (オプション) Description にコレクションの説明を入力します。 Collection groups セクションで、コレクションを割り当てるコレクショングループを選択します。コレクションは一度に 1 つのコレクショングループにのみ所属できます。 (オプション) Create a new group を選択して新しいグループを作成することもできます。コレクショングループの作成が完了したら、ステップ 1 に戻って新しいコレクションの作成を開始します。 ワークフローを続行してコレクションを作成します。 コレクショングループの管理 コレクショングループを作成したら、アーキテクチャの進化に合わせて設定を更新できます。 Amazon OpenSearch Serverless のドキュメント に、AWS マネジメントコンソール、CLI、CloudFormation でのコレクショングループの編集・削除、OCU 制限の更新、グループ設定の変更に関するステップバイステップのガイダンスがあります。 まとめ OpenSearch Serverless のコレクショングループは、セキュリティ要件と運用効率を両立する柔軟なデプロイモードを提供し、マルチテナントデプロイのアーキテクチャを変革します。コレクショングループで論理的なセキュリティ境界を定義し、同じ KMS キーを共有するか異なる KMS キーを使用するかに関係なく、コレクション間で OCU リソースを共有できます。 コレクショングループの柔軟性は、従来マルチテナントデプロイを困難にしていたコスト課題に直接対応します。コレクショングループ内にコレクションを統合することで、暗号化とテナント分離を維持しながらインフラストラクチャコストを削減できます。各コレクショングループに最小・最大 OCU の両方を設定することで、コールドスタートとキャパシティ保証の課題を解決します。最小 OCU により、コレクションは高速取り込み、突発的なトラフィックスパイク、負荷テストをパフォーマンス低下なく処理するための準備済みコンピューティングリソースを維持します。最大 OCU はコストの予測可能性と支出制御を提供します。最小・最大の二重設定により、コールドスタートの不確実性とコスト超過のリスクの両方を排除するリソース範囲が明確になります。 コレクショングループと最小 OCU 設定の詳細については、 Amazon OpenSearch Serverless のドキュメント をご覧ください。 著者について Madhusudhan Narayana Madhusudhan は、Amazon Web Services のシニアソフトウェアエンジニアです。OpenSearch Service に注力しており、ソフトウェアエンジニアリング、分散システム、自律システムの分野で長年の経験があります。コンピュータサイエンスの修士号を取得しています。 Prashant Agrawal Prashant は、Amazon OpenSearch Service のシニアサーチスペシャリストソリューションアーキテクトです。仕事以外では旅行や新しい場所の探索を楽しんでいます。食べる → 旅する → 繰り返す、がモットーです。 Xian Huang Xian は、AWS のプロダクトマーケティングマネージャーです。 この記事は Kiro が翻訳を担当し、Solutions Architect の 榎本 貴之 がレビューしました。

こんにちは。株式会社SHIFTのCATエヴァンジェリスト・石井優です。 （情報）統合型ソフトウェアテスト管理ツール「CAT」について 現在SHIFTが提供するCATとは、テストの実行管理に主眼を置いた正式名称「CAT TCM（Test Cycle Management）」という製品を指します。ケースと実行結果・エビデンスの管理、およびプロジェクトの進捗管理や品質分析を担うツールです。詳しいご紹介はぜひ 製品HP をご確認ください。

こんにちは、タイミーでバックエンドのテックリードをしている新谷（ @euglena1215 ）です。 今回は、社内向けに公開したバックエンド開発Handbookと、それをClaude CodeやCursorといったAIエージェント向けスキルとして届けることで、気づいたらHandbookを参照している状態を目指した取り組みについて紹介します。 バックエンド開発Handbookとは何か バックエンド開発Handbookは、タイミーのバックエンド開発における設計・実装・運用のガイドラインをまとめたドキュメント集です。GitHub Pages でホスティングし、開発者が見やすい形で公開しています。 タイミーでは GitHub Enterprise Cloud を利用しているため、GitHub Pages のアクセス制御機能でリポジトリの読み取り権限を持つメンバーのみに公開範囲を制限できます。 バックエンド開発トップページ なぜ書き始めたのか 事業の成長・変化に伴い、バックエンド開発に関わるエンジニアが増えてきました。AIツールの進化も相まって、バックエンド以外を専門とするエンジニアが越境してコードを書く機会も増えています。 こうした変化の中で、これまでチーム内で暗黙的に共有されてきたノウハウや設計思想を形式知として残し、誰でもアクセスできる状態にしておく必要がありました。 たとえば戦略的プログラミングの重要性、概念モデリングの進め方、テーブル設計の注意点など、日々の開発で繰り返し必要になる判断基準を体系化しています。 カバー範囲 Handbookは開発プロセスの全体を一気通貫でカバーしています。 フェーズ トピック はじめに 戦略的プログラミングの心構え、秘匿情報の取り扱い、タイミーを取り巻く法律 設計 概念モデリング、ギャップ分析、テーブル設計、Web API設計、クラス設計、非同期処理設計、バッチ処理設計 実装・レビュー 実装ガイドライン、コードレビュー、自動テスト設計、コードの整頓 運用・保守 ログ設計、監視、障害対応 リリース デプロイ・リリース 設計に重点を置いているのは、バックエンド開発に慣れていない人がAIエージェントを使ったとしても、カバーしにくい領域だからです。実装やレビューのプラクティスはある程度一般化されていますが、「タイミーのバックエンドとしてどう設計するか」はチーム固有の知見が多く、形式知にする価値が高いと考えました。 たとえばタイミーでは、Sidekiq ジョブ実行中にデプロイが行われると、Sidekiq プロセスに SIGTERM が送信されます。その25秒後にたとえ実行途中であってもジョブをキューに戻す、という実装上の制約があります。開発者はこれを考慮してジョブの処理をべき等にしたり、25秒を超えないように処理対象を分割してジョブに切り出すなどの対策を行う必要があります。このような暗黙的かつ独自の制約は特に Handbook として残すべきだろうと考えていました。 Handbookをどう届けるか Handbookを書いて公開するだけでも価値はありますが、ドキュメントは自分から読みに行く必要があり、ひと手間かかります。存在を知っていても、忙しい開発中には思い出せないこともあると思います。 いま、社内の多くのエンジニアがAIエージェントを日常的に使って開発しています。Claude CodeやCursorなどのツールが開発フローに組み込まれているのであれば、 AIエージェント経由でガイドラインを届ける という選択肢があります。 開発者が意識しなくても、AIエージェントがガイドラインを参照しながら設計や実装を支援してくれる。そうすれば、「気づいたらガイドラインに沿った開発をしていた」という状態を作れます。 この考えから、Handbook公開と同時にAIエージェント向けスキルとしても提供することにしました。現在、Claude Code Plugin と Cursor Agent Skills の2つの形式で配布しています。 ここからは、AIエージェント向けスキルの技術的な仕組みと、人間側の学びを促す工夫の2つの観点で説明します。 スキルの技術設計 リポジトリ構成 1つの工夫として、Handbookのマークダウンドキュメントとスキル定義を同じリポジトリに同居させています。 handbook/ ├── backend/ # Handbookドキュメント（マークダウン） │ ├── design/ │ │ ├── web_api_design.md │ │ ├── table_design.md │ │ └── ... │ ├── implementation/ │ └── operation/ ├── .claude-plugin/ # AIエージェント向けスキル定義 │ └── timee-backend-handbook/ │ ├── plugin.json │ └── skills/ │ ├── ref-design-api/ │ ├── wf-code-reading/ │ └── ... └── scripts/ └── build-cursor-skills.sh # Cursor向け変換スクリプト ガイドラインの原文とスキル定義が同じリポジトリにあるため、ドキュメントの更新とスキルの更新を同じPRで行えます。ドキュメントとスキルが乖離するリスクを構造的に減らせます。 Reference SkillsとWorkflow Skills Handbookの内容を、AIエージェントのスラッシュコマンドで呼び出せるSkillsとして提供しています。今回、スキルの役割に応じて Reference Skills と Workflow Skills という2種類の分類を独自に定義しました。これはClaude CodeやCursorの公式な分類ではなく、Handbookスキル群の設計方針として導入した概念です。 Workflow Skill（高レベル） ├── Reference Skill A を呼び出し ├── Reference Skill B を呼び出し └── Reference Skill N を呼び出し（必要に応じて） Reference Skills Reference SkillsはHandbookの各ページと1対1で対応します。 /handbook-ref-design-api # Web API設計 /handbook-ref-design-table # テーブル設計 /handbook-ref-design-class # クラス設計 /handbook-ref-impl-code-review # コードレビュー ... たとえばAPI設計のReference Skillsは以下のように定義されています。 --- name: handbook-ref-design-api description: Web API設計のガイドラインを参照してエンドポイント設計をレビュー・提案 context: fork agent: general-purpose allowed-tools: Bash(gh *) --- ## Web API設計ガイドライン !`gh api /repos/my-org/handbook/contents/backend/design/web_api_design.md -H "Accept: application/vnd.github.raw"` ## タスク 上記のガイドラインに従って、$ARGUMENTS のWeb API設計をレビュー・提案してください。 ポイントは context: fork です。サブエージェントとして独立したセッションで実行されるため、メインセッションのコンテキストウィンドウを消費しません。情報量の多いHandbookの取得をサブエージェントに委譲し、要約のみを返すことで効率的に運用できます。 また、 gh api -H "Accept: application/vnd.github.raw" でマークダウンの原文をそのまま取得できます。Handbookが更新されれば自動的に最新の内容が反映されます。 Workflow Skills Workflow Skillsは、状況に応じて複数のReference Skillsを組み合わせるユースケース特化型のスキルです。 context: current でメインセッション上で実行されます。 現在はWorkflow Skillsを4つ提供しています。 スキル フェーズ 内容 /handbook-wf-code-reading 理解 既存機能を体系的に理解する /handbook-wf-modeling モデリング 概念モデリングを実施する /handbook-wf-plan 計画 開発中: 詳細設計を行いつつ、複数個の実装計画に落とし込む /handbook-wf-implement 実装 開発中: 与えられた入力を元に実装する たとえばモデリングフェーズのWorkflow Skillsを実行すると、以下のような流れで進みます。 イントロダクション : 概念モデリングの重要性とギャップ分析の考え方を説明 ガイドライン取得 : 必要なReference Skills（概念モデリング、ギャップ分析など）を自動で選択・呼び出し 意図の深掘りと目標の合意 : 何をモデリングしたいのか、スコープを確認 すり合わせの質問 : ドメインの境界やビジネスルールについて質問を提示 メインセッションでモデリング実行 : 回答を踏まえて一緒にモデリングを進める 開発者はスラッシュコマンドを1つ実行するだけで、必要なガイドラインの参照からモデリング作業までを一気通貫で進められます。ガイドラインの存在を知らなくても、Workflow Skillsが自動的に適用してくれます。 階層構造のメリット Reference SkillsとWorkflow Skillsの2層構造には、以下のメリットがあります。 再利用性: 同じReference Skills（たとえばギャップ分析）が理解・モデリング・設計の各Workflowから呼ばれる 動的選択: Workflow Skillsがユーザーの入力や状況に応じて、必要なReference Skillsだけを選択的に呼び出す コンテキスト効率: ガイドラインの取得処理はサブエージェントに委譲され、メインセッションには要約のみが返る また、Workflow Skillsは自作も可能です。既存のWorkflow Skillsを参考にしながら、チームの開発フローに合わせたワークフローを追加していけます。こうしたスキルが充実すれば、どのタスクに取り組むときでもHandbookの知見にガイドされる状態が作れます。新しくチームに加わった開発者でも、スキルを通じてすぐにチーム固有の設計方針をキャッチアップできるはずです。 人間の理解を置き去りにしない設計 スキルの技術設計だけでは不十分です。ここが一番気をつけたポイントです。 AWSが提唱しているAI-DLC（AI Driven Development Life Cycle） は、AIの出力を妥当にジャッジできる人間の存在を前提としています。人間側の理解が伴わなければ成り立ちません。 しかし現実には、AIの出力を「なんか良さそうだから」とそのまま使ってしまい、人間側の理解が追いつかないケースも起きがちです。AIの進化によって実装の詳細を人間が把握しなくてよくなる部分はあるでしょう。ですが、背景にある考え方を理解していなければ、AIと適切にコミュニケーションを取ることはできません。 だからこそ、このスキル群では人間に考え方やインサイトをインプットする工夫を随所に入れています。いわば、いつでも質問できるメンターをAIで実現する試みです。 工夫点１：イントロダクションで「なぜ」を伝える 各Workflow Skillsの冒頭にイントロダクションを設けています。ここではいきなり作業に入るのではなく、「なぜこのフェーズが重要なのか」「このフェーズで何を学ぶのか」を説明します。 たとえば理解フェーズのイントロでは、コード理解には概念・構造・実装の3段階があり、概念レベルから順に深めるアプローチが有効であることを説明しています。 ## 推奨アプローチ 概念レベルから順に理解を深めることを推奨します： 1. 概念レベル: まず全体像を掴む（どんな世界なのか） 2. 構造レベル: データとクラスの設計を理解（どう表現されているか） 3. 実装レベル: 具体的なロジックを理解（どう動くのか） 工夫点２：ガイドラインURLの提示 全てのスキルで、参照したガイドラインのホスティングしているURLを、ユーザーに必ず提示するようにしています。 重要: 参照したガイドライン（https://{my-org}.github.io/handbook/backend/design/web _ api _ design.html） をユーザーに必ず提示してください。 AIの要約だけで完結させず、元のドキュメントに戻れる導線を用意しています。全体像を掴んだ上で、気になった箇所は原文で深掘りできます。Handbookそのものの認知と活用が進む効果も期待しています。 工夫点３：抽象から具体へ段階的に Workflow Skillsのフロー全体が、抽象度を段階的に下げていく設計になっています。 ワークフローの4フェーズ（理解→モデリング→計画→実装）がそうですし、各フェーズ内でも同様です。理解フェーズでは概念→構造→実装と段階的に深め、計画フェーズでは概念モデルの出来事やモノをAPIエンドポイントやテーブルへ変換していきます。 一気に情報を出すのではなく、フェーズごとにすり合わせの質問を挟むことで、開発者自身が考える余白を作っています。 以下は、思考実験として「タイミーで企業合併を表現するなら？」というお題で、モデリングのWorkflow Skillsを試したときの様子です。 「将来の新設合併対応を見据えて、今回のモデルはどの程度汎用的にすべきですか？」「合併には時間的なフェーズがありますか？」という質問が飛んできました。そもそも合併に吸収・新設のパターンがあることを私は知りませんでした。Handbookの設計ガイドラインを熟知したエキスパートと、ドメイン知識を持ったエキスパートが悪魔合体するとこんな体験になるのか、と末恐ろしくなった瞬間です。 工夫点４：各ステップに学習ポイントを明示 Workflow Skills内の各ステップには「なぜそうするのか」「ここで何を学ぶか」を明示しています。 📚 学習ポイント: - 出来事（申請する、承認する）→ APIエンドポイント - モノ（勤務実績、勤務時間）→ リソースとリクエスト/レスポンス - ビジネスルール → バリデーションとエラーハンドリング 💡 ガイドラインのポイント: - 出来事は動詞で考え、APIでは名詞（リソース）として表現 - 選択された名前（例：「勤務実績」）をリソース名に反映 作業の手順だけでなく、その背景にある考え方を一緒に伝えることで、AIが出す結果の「なぜ」を開発者自身が理解できる状態を目指しています。 使ってみての感想 自分自身の所感 実際に使ってみて、これまでとは一線を画す体験だと感じています。 従来のAIエージェントの出力は、一気にたくさんの情報を出してくることが多く、情報量に圧倒されて消化しきれないことがありました。ですが、このワークフローでは抽象度を段階的に下げながら教えてくれるので理解がしやすいです。普段の会話で賢いなと感じる人は、抽象的なところから徐々に具体へ落としていくのが上手ですが、このワークフローにも同じ感覚があります。 AIエージェントは便利な開発アシストツールだと思いつつも、開発のギアが上がる感覚はこれまでありませんでした。ですが、このワークフローは明確にゲームチェンジャーだと感じています。 VPoEの反応 VPoEに実際に動かしながら紹介したところ、その場でEMチャンネルに @here 付きで共有してくれました。特に、AIエージェントが段階的にガイドラインを適用しながら開発者と対話する体験に手応えを感じてもらえたようです。 語彙力が下がっているVPoE 他開発チームメンバーの反応 現在、社内への全体発信を終えて各チームへのハンズオンを順次進めているところですが、すでに手応えを感じ始めています。 既に普段の開発で使ってくれているエンジニアからはこんなコメントをもらっています。ありがたい限りです。 handbookはここ1,2年で一番自分に刺さったプロダクトです おわりに この記事では、バックエンド開発Handbookと、それをAIエージェント向けスキルとして届ける取り組みについて紹介しました。 ドキュメントを書くだけでなく、AIエージェントを介して開発フローへ自然に組み込むことで、ガイドラインを届ける新しいアプローチを模索しています。AIへ任せきりにせず人間側の理解を促すことが、知の高速道路を敷くうえで最も大事なポイントだと考えています。 今回の取り組みを通じて、AI時代の開発組織に必要な要素が見えてきた気がしています。短期目線での開発の高速化だけでは不十分で、「全タスクがオンボーディングタスクになっていること」「メンターを基本的にAIが担い、いくらでも質問できて自走できる環境が整っていること」。この2つが揃えば、誰でもどのチームに移っても素早く立ち上がれるようになります。つまり、必要な場所に必要な人材を配置できる人員の流動性の高さに直結します。Handbookとスキルの取り組みは、その第一歩です。 今回作成した Agent Skills はカジュアル面談でもデモできるので、興味ある方はお気軽にお声がけください！実際に触ってみたい方は、ぜひタイミーに入社してください！ product-recruit.timee.co.jp