要件から実装までの“流れ”を自動化する：手作業を減らしてスムーズに進める

私の組織は最近、大規模な組織再編を行いました。数週間のうちに、私のチームは規模を2倍にし、責任も増えました。AWSの口座を少数支えるところから、複数のプロダクトラインにまたがるインフラを自分たちで保有するようになり、（他のインフラチームとともに）複数のクラウドプロバイダーを担当し、国をまたいで分散する数百人のエンジニアを支える立場になりました。

再編に伴い、私たちが選ばなかった変化もいくつかありました。その1つがJiraからLinearへ移行すること（正直、私は歓迎しています）です。もう1つは、あまりスケールしないコラボレーションプロセスを引き継ぐことでした。

この新しいマルチクラウド構成では、クラウドオペレーション（cloud-ops）のエンジニアは、プロダクトチームのエンジニアがLinearに直接チケットを作成することに消極的でした。バックログが散らかるのではないか、あるいは誤ったチーム（AWS? GCP? Azure?）に紐づけてしまうのではないかと心配していたのです。そこでデフォルトは、共有チャンネルに投稿する単純なSlackメッセージになりました。プラットフォームドメインの誰かがそれを読み、頭の中でトリアージする、そして正しいチームのためのLinearチケットをその後手作業で作成します。

そのプロセスはすでに、Slack Workflowを追加することで最近改善されていました。フォームを使ってリクエストを構造化する仕組みです。それでもトリアージ対象はSlackメッセージですが、少なくとも関連情報がうまく整理された形になっています。

さらに踏み込めると考えました。徹底的に自動化し、そして何よりも、手作業の負担（マニュアルな手間）とノイズを減らすことです。

AI-Assisted Flow from Request to Implementation

私の目標は、ストリームラインされたパイプラインです：

1. Slackを入口にする：エンジニアはLinearに触る必要がなく、どのチーム／ワークスペースを対象にすべきかを知る必要もありません
2. 自動化が、リクエストを適切なチームの構造化されたチケットに変換する（AIが追加のコンテキストをいくらか補完する）
3. AIによるトリアージで、チケットが完結していて、正しくラベル付けされ、実行可能な形になっていることを保証する
4. 仕様（Spec）駆動の開発で、うまく説明されたチケットを、誰でも拾って対応できる要件やタスクへと変換する

使うツール：Slack Workflows、LinearのSlack統合、LinearのMCPサーバー、そしてKiro（カスタムスキル2つ：Ticket Triage と Platform Support）です。

Step 1: Slack as the Front Door

当初、チームの負担を減らすために（多くの場合、カルチャー／組織的な変更が最も難しく、時間もかかるからです）、私たちは同じMultiCloudのチャンネルを維持することにしました。
ある日から別の日へと、プロセスそのものを中断して混乱させたくなかったので、リクエストの流し込みを簡単にするためのいくつかの決め事を追加しました（Slack Workflowsは非常にシンプルで、高い自由度でカスタマイズできます。トリガーの種類、フォームを開くなどの複数アクションの連鎖、入力されたデータの加工、チャンネルへの転送、あるいは何か別のものをトリガーすることなど）。

• 既存のワークフローを編集して、クラウドプロバイダーが分かっていれば記載する（または例えばリポジトリ名から推測できるようにする）ようにしました。たとえば、リポジトリがaws-terraform-modulesという名前なら、どのプロバイダーのことか分かりますよね。
• もう1つ、リクエストの後（またはSlack上のどんな会話の最中でも）に、適切なクラウドプロバイダーの絵文字を使うだけで、正しいチームに自動的に通知するワークフローを追加しました。

これにより、初期の手作業トリアージはより素早くなり、チームを直接正しく指定するコツも人々が掴めました。さらに、多くのトピックでは、データベースへのアクセス権の依頼、S3バケットへのアクセスに関する権限の依頼、Terraformコードを修正するためのPRを開くといった内容で、依頼者は関わるクラウドプロバイダー／プラットフォームチームがAWSなのかGCPなのか分かっていることが多いため、私たちは段階的に専用チャンネルへ移行しました。共有チャンネルは移行期間だけ（または所有がまだ不明な依頼：例えばCloudflareやDatadogのインフラをコードとして扱うリポジトリなど）に限定しました。

Triggering the workflow

私たちのケースでは、チャンネル内に明示的なボタンを残すことを選びました。

ただし、ワークフローは単純なショートカットでも動作します。つまり、チャンネルのメッセージ作成欄で/awsと入力すると、フォームが表示されます：

フォームでは基本を聞きます：何が必要か、なぜ必要か、そしてどれくらい緊急かです。送信されると、その内容は可視性のためにチャンネルへ投稿され、続いてLinearのSlack AI統合を通じてLinearへルーティングされます。

Why not Linear's default Slack integration?

Linearの標準Slack統合（/linear）は、どのチーム・プロジェクト・ラベルを選ぶべきかをすでに知っているエンジニアにとっては問題なく機能します。しかし、マルチクラウドのプラットフォーム組織にまたがってリクエストを出すステークホルダーにとっては、それだけでは不十分でした。特に重要なのは、フォームの項目が堅すぎたことです（私たちのサイクル、ラベル、懸念事項のカスタマイズが欠けている）。その結果、説明不足のチケットが生まれてしまいました。

Slack Workflow経由で処理し、AIにフォームの内容を解析させることで、より豊かなチケットが得られます。AIはコンテキストを追加し、構造を推定し、チケットを私たちにとって最も関連のある領域（見積りや優先順位付けに関して重要なところ）に最適化する形で埋めていきます。

Step 2: AI-Assisted Triage: Making Tickets Actionable

ここからがより面白くなります。特に、AIネイティブなSDLCとAIツールの活用という観点でです。

What is triage, anyway?

トリアージという言葉は救急医療に由来します：看護師が各患者の状態を短時間で評価し、リスクと緊急度を判断して、実際の治療を行うことなく適切な場所へ振り分ける、というものです。
返却形式: {"translated": "翻訳されたHTML"}

ソフトウェアのトリアージも同じです。まだ問題を解決しているわけではありません。問題がよく理解され、正しく優先度付けされ、誰かが取り掛かれる適切なキューに入っていることを確認しているのです。

私たちのケースでは、チケットがトリアージ・インボックスに届いたら、レビューが必要です。実行可能な内容ですか？優先度は現実的ですか？本当にクリティカルなブロッカーですか、それとも単に次のサイクルで計画すればよいだけですか？（多くの場合、メッセージは過剰にドラマチックであり、設定／推定された優先度と期限（due date）が一致していません。）ラベルは正しいですか？説明文には、誰かが作業を始めるのに十分な情報が含まれていますか？

チケット・トリアージのスキル

まず私はこれをKiro Agentとして作り、その後Agent Skillに変換しました。Kiroを使っていない同僚でも恩恵を受けられるようにするためです。

実際のところ、自分でカスタムのサブエージェントを作って使うことは大変楽しいのですが、多くの状況で「スキル」のほうがより便利だと感じるようになりました（steering filesよりも優れたコンテキスト管理、単純なプロンプトよりも多いコンテキスト、繰り返しのある限定タスクのたびにエージェントを切り替える必要がないこと）。欠けているのは、MCPサーバーと許可されたツールの自動設定だけです。

このスキルはLinear MCPサーバーに接続し、チケットを取得して、構造化されたアセスメントを行います：

• 課題の分類（Issue classification）：投稿者が推測した内容ではなく、本文のシグナルに基づいて正しいタイプ（story、bug、support-request、technical-improvement、spike、security）を判定します
• 優先度の評価（Priority assessment）：一貫したスケールに照らして評価します（Urgent = 本番停止；High = ブロッキングの作業；Normal = 通常の機能；Low = あると嬉しい）
• 不一致の検出（Discordance detection）：トーンと優先度、説明と緊急度、優先度と期限の間の食い違いを見つけます。「URGENT!!!」とパニック気味に叫んでいて期限が3週間先ならフラグが立ちますし、本当の本番ブロッカーを隠すように落ち着いた説明文でもフラグが立ちます
• 網羅性の評価（Completeness evaluation）：明確な問題設定、受け入れ基準、正しいラベル、適切な見積り、依存関係、そして最も重要な「なぜ（ビジネス価値またはユーザーのニーズ）」が含まれているかを確認します
• 懸念のマッピング（Concern mapping）：関係するインフラ領域（ネットワーキング、compute、ストレージ、CI/CD、可観測性、セキュリティ、IaC）を特定し、適切なラベルを適用します
• 洗練（Refinement）のガイダンス：チケットが準備できていない場合、メモリがまだ鮮明なうちに、投稿者へ返すための具体的な質問を生成します

内側では：スキルはどのように構造化されているか

Kiro スキルは本質的に構造化された markdown ファイル（SKILL.md）で、フロントマターのメタデータと、詳細なプロンプトとして機能する本文を持ちます。スキルが有効化されたとき、AIエージェントが従う一連の指示、意思決定ツリー、参照データのセットです。

トリアージ・スキルに含まれるものは以下です：

1. フロントマター（Frontmatter）：名前、説明、そして Kiro に「いつスキルを有効化するか」を伝えるトリガーとなるキーワード：

---
name: triage-ticket
description: Triage and refine Linear issues through structured analysis.
  Evaluates issue quality, detects discordance between tone and priority,
  and enhances metadata.
---

2. 前提条件（Prerequisites）：スキルが依存する MCP サーバーです。今回の場合、チケットの取得と更新のために Linear MCP サーバーが必要で、実装時の提案のためにリポジトリ探索が必要な場合は GitHub MCP サーバーは任意です：

{
  "mcpServers": {
    "linear": {
      "command": "npx",
      "args": [ "-y", "mcp-remote", "https://mcp.linear.app/mcp"]
    }
  }
}

3. 手順ベースのワークフロー：スキルは構造化されたトリアージ手順（fetch → classify → assess priority → detect discordance → evaluate completeness → produce report → research context → enhance）を定義します。各ステップには明示的な指示、意思決定テーブル、出力形式があります。例えば、不一致の検出ステップには、シグナルのパターン表が含まれます：

**トーンと優先度**: 緊急な言葉（「ASAP」「critical」「immediately」「blocking」）が Normal/Low 優先度と組み合わさっていないか確認します。または、カジュアル／探索的な言葉が Urgent/High 優先度と組み合わさっていないか確認します。

**優先度と期限**: Urgent/High 優先度なのに期限が遠い、または期限が欠けている場合。Low 優先度なのに期限がすぐである場合。

4. 参照テーブル：懸念のマッピング用キーワード、優先度スケール、期限（due date）のガイドライン、見積りレンジ、ラベル定義です。これらにより、AIは一般的な知識に頼るのではなく、一貫した基準を得られます：

5. 安全ルール（Safety rules）：たとえば「元の説明文を決して上書きしない」「変更する前に必ず確認する」「実装の提案はコメントに書き、本文中に直接書かない」といった明示的な制約があります。これにより、AIが変更に対して過度に強気になることを防ぎます。

6. スキルの構成（Skill composition）：トリアージ・スキルはステップ7の間に、プラットフォーム・サポート・スキルを明示的に呼び出します。これはスキル本文中で依存関係として宣言されています：

## 依存: platform-support skill

このスキルは、トリアージ（ステップ7）の間に`platform-support`スキルを有効化し、
我々のエコシステム内における実装の文脈を理解します。

この構成パターンは強力です。各スキルは自分の領域に集中したままですが、より豊かなアウトプットのために連結することができます。トリアージスキルが扱うのは何となぜです。platform-supportスキルが扱うのはどことどのようにです。

トリアージスキルが依存しているPlatform-Support Skillとは、基本的にインフラの生きた地図です

これは、最近のリオーグで統合されたさまざまなインフラチームのメンバーを受け入れやすくし、現在の複雑さの中でナビゲーションを簡単にするための手段として生まれました。しかし私たちの目標は、十分に徹底的にテストした後、機能チームにもリリースし、彼らが一次のサポートとしてそれに頼れるようにすることです（汎用の依頼をSlackチャンネルに投げ込むのではなく、私たちのスキルを使ってAIエージェントに質問します）。

Platform Supportスキルは、どのリポジトリが何を所有しているか、どのTerraformモジュールが存在するか、どのAWSアカウントと環境が関わっているか、私たちのCI/CDのパターンがどのようなものか、そしてどのプラットフォームの慣例（タグ付け、命名、安全性のデフォルト）が適用されるかを把握しています。

トリアージ中は、これにより次が可能になります:

• 提案する実装は、汎用的な助言ではなく実在するリポジトリ、モジュール、ワークフローを参照する
• 影響を受けるAWSアカウントと環境を正しく特定する
• 要求されている内容に対してプラットフォームモジュールが既に存在する場合、そのモジュールを提示する（重複作業や、生のリソース作成を避ける）
• エスカレーション経路が正しいチャンネルを指す

例えば、誰かが「サービスX用に新しいS3バケットが必要だ」と依頼した場合、トリアージは単にラベル付けして終わりません。サービスが存在するアカウントを特定し、私たちのterraform-module-libraryにS3モジュールがあるかを確認します（例えば、セキュリティとコンプライアンスの制御を埋め込み、適切なデフォルトを設定しているような箇所です）。必要なタグと暗号化のデフォルトを確認し、実際にエンジニアが追って実装できる実装提案を作成します。

出力はどのように見えるか

トリアージ後、チケットは2つのセクションに明確に拡張されます。

1. 強化された説明: 問題の種類（ユーザーストーリ形式、バグ報告形式など）で構造化し、受け入れ基準を含めます。元の説明は、区切りの下に必ず原文のまま保持されます。区切りは明確に(Original Request)としてマークされます。私たちは、レポーターが書いた内容を決して上書きしません。

2. 実装計画: コメントとして追加され、明確に(AI Generated Suggested Implementation)が接頭辞として付けられます。これには、関連するリポジトリ、影響を受けるアカウント/環境、適用可能なプラットフォームモジュール、具体的な手順、従うべき慣例が含まれます。

私たちは意図的に、すべてのAI生成物であることを明示します。出力の品質に対する信頼がさらに高まるまでは、そしてチームがプロセスを信頼できるようになるまでは、透明性が重要です。エンジニアは、どれがレポーター由来でどれがAI由来かを正確に把握でき、文脈を失うことなくAIの提案を上書きまたは破棄できます。

はっきり言って、これは目を見張るほど画期的なものではありません。そしていずれ、AIによる自動化にこれだけ労力をかける価値が、クレジット/トークンに見合うのかを検討することになるかもしれません。ただ私にとっては、掛け算のように増幅する効果は本物です。これを手作業でできないわけではありません。もちろん可能です。しかし、AIアシスタントを使い、しかも文脈を維持したまま（ウィンドウを切り替えることなく）やると、週に何十件ものチケットの積み重ねの中で効果が増幅します。摩擦が減ることで、トリアージは積み上がるのではなく、迅速に行われます。そして一貫性も向上します。誰がトリアージしているか、またその週がどれくらい忙しいかにかかわらず、すべてのチケットが同じレベルの精査を受けるのです。

ステップ3: トリアージから実装へ、そして仕様駆動開発へ

ここでパイプラインの成果が効いてきます。

チケットが、明確な文脈を伴って十分に説明され、適切なラベルが付けられ、現実的な優先度が設定され、懸念点が特定され、「なぜ」がしっかりしており、さらにAIによる実装計画が、私たちの実際のエコシステムに根ざした形で用意できていれば、あとは引き継いでもらう準備が整います。

今日私たちがやっていること

現時点では、トリアージの出力には既に、チケットに対するコメントとして提案された実装計画が含まれています。これは完全な仕様書ではありません。あくまでラフなガイドです。つまり、どのリポジトリに触るべきか、どのモジュールを使うべきか、どのアカウントが影響を受けているか、どの慣例に従うべきか、ということを示します。Todoカラムからチケットを取ってきたエンジニアに、最初の一歩を提供し、真っ白な状態から始めさせないのです。

そこからエンジニアは、Linear MCPサーバー経由でチケットをIDEに取り込みます。単純な作業であれば、実装計画だけでコーディングを始められます。複雑な作業であれば、Kiroに適切な仕様駆動開発のセッションを開始してもらい、構造化された要件、設計上の意思決定、粒度の細かいタスクを生成できます。各ステップは、前のステップに積み上げる形で進みます。その後、仕様はドキュメントとしてLinearのチケットに戻すことができ、関係者全員が可視性を得られます。

私たちはまだ仕様を自動で反映していません。これは次のステップです。そして正直なところ、仕様が、AIが生成したコードそのものではなく、バージョン管理して差分を取る単一の真実の情報源になるとまでは、私はまだ確信が持てていません。なので現時点では、仕様はフィーチャーブランチ上に存在します（mainには着地しません）。そしてチケットにはコメントとして実装計画が付与されます。今はそれで十分です。改善していきます。

仕様の品質は、チケットの品質に完全に依存します。トリアージが雑だと、仕様は曖昧になります。上流でAI支援付きのトリアージに投資し、Platform-Support Skillを通じて実際のインフラ文脈に根ざすことで、下流のあらゆる作業を劇的に有用なものにします。

フルパイプライン

これらのどのステップもAIを 必要としません。エンジニアはすべてを手作業で行えます。ですが、「小さな摩擦」を取り除くことで得られる複合的な効果、タブ切替、コピペ、「あのSlackスレッドをもう一度読み直させて」、一貫性のないトリアージ――それらが積み重なり、今や数百人のエンジニアからの依頼を扱うチーム全体で、週あたりの数時間になります。

以前は、たとえチームが小さく、スコープも狭く、数か月〜数年にわたって一緒に働いてきたメンバーがいても、時間のかかるAgileの儀式に頼っていました。バックログのリファイン、見積もりポーカー、スプリント計画です。私たちは実際に特定のチケットが何の話だったかを思い出すのに時間を浪費してしまうことがよくありました。説明が良くなかったり、チケットが単なるプレースホルダー（基本的にタイトル）だったりして、私たちは「これを作業しないといけない」と分かっていたものの、バグ修正なのか改善なのか、覚えておくべき内容を思い出せないからです。良いトリアージは、その種の無駄を丸ごと排除します。

私が学んだこと

まず受付から始めます。 最初の時点でチケットが薄く、構造化されていなければ、下流のすべてが影響を受けます。

段階的に進める。 私たちは一度に全部を作り直しませんでした。最初にSlackのワークフロー、次にLinearのMCP統合、次にトリアージのスキル、そして仕様です。それぞれのステップが単独でも価値を提供し、次の段階の土台を築いていきました。

食い違いを早期に検知する。 トリアージのスキルが最も価値を生むことの1つは、トーンと優先度が一致していないときにフラグを立てることです。焦ったメッセージにリラックスした期限（または落ち着いた依頼の裏に、本番でのブロッカーが隠れている）――そうしたものは、計画を歪める前に見つかります。同様に、チケットに追加のリファインが必要かどうかも即座に明らかになるため、記憶がまだ鮮明なうちに、レポーターへ連絡して依頼を跳ね返したり、明確化を求めたりできます。

AIは置き換えではなく、掛け算（マルチプライヤー）として最も効果的です。 エンジニアは引き続きトリアージし、判断を下し、コードを書きます。AIが担うのは機械的な部分――解析、構造化、食い違いの検出、文脈の取得です。だからこそ、エンジニアは意思決定に集中できます。

次に何をするか

• プラットフォームサポートおよびトリアージスキルを、より包括的なアシスタントへ進化させる
• チケットの割り当てによってトリガーされる自動仕様生成
• トリアージと実装そのものを、AI支援できるかを検討する

今後数週間〜数か月のうちに、さらに自動化を進めたいと思っています。最近リリースされたKiro Headless Modeにより、CI/CDパイプライン内で動かせるようになったので、Linearをパイプラインに組み込み、まずは自動で一次レベルのトリアージを行い、情報が不足しているチケットは差し戻し、他のチケットは私のチームへ明確化のために転送し、人の介入なしにチケットを濃縮（エンリッチ）できるようにしたいです。

夢のシナリオ

社内ユーザーがSlackで依頼を作成すると、Linearのチケットが生成され、Kiroエージェントがそれを受け取り、トリアージして仕様を作成し、その後別のエージェントが仕様に沿って変更を実装し、直接PRを開いてチケットを「In Review（レビュー中）」へ移動します。
さらに、AIによるカスタムのPRレビュー用スキルもあるので、レビュー自体も部分的に自動化できるはずです。デプロイ前の最終承認だけは人間がループ内にいる形で。

依頼からPRまで、あらゆるステップでAIが面倒な作業を引き受けます。人間は、最も重要な場所に残ります。つまり最終判断です。

ですが、私はあえて急いでそこまで行こうとはしていません。私のチームはこのスコープにまだ新しく、組織再編で引き継いだ複数のリポジトリやアカウントの複雑さをいまも手探りで進んでいます。
そして何より、AIの導入のされ方はチームメンバーによって違います。大いに期待して（そしてときには過度に頼りすぎて）いる人もいれば、懐疑的な人もいます。
私が取っているアプローチは、退屈で反復的な作業が自動化されていく様子を見せつつ、実際のコーディングの楽しさをできるだけ残すための「小さな一歩」です。

誰も「置き換えられる」感じは欲しくありません。誰も「詰まらされて動けない」感じは欲しくないのです。

AIがトリアージ、雛形（ボイラープレート）、チケットのエンリッチ、PRの説明文などの手間を引き受けられることを示しつつ、エンジニアには面白い意思決定や創造的な課題解決を残せるなら、導入は自然に進むはずです。

私たちはこの道の初期段階にいますが、方向性は明確です。文脈切替を減らし、フローを増やす。そして、エンジニアがSlackメッセージを投稿した瞬間からコードが出荷される瞬間まで、AIをあらゆる段階でパートナーとして使う。

あなた自身でも試してみたいですか？

現時点での正確なスキルセットは共有できません。社内の内部情報をかなり参照しているからです（リポジトリのインデックス、アカウントのマッピング、NotionページID、チーム固有の慣習など）。ただし、私のGitHubで汎用的でカスタマイズ可能なバージョンをリリースし、あなたの組織のセットアップに合わせてフォークして適応できるようにする予定です。構造とワークフローのロジックは同じで、あなたは自分のリポジトリ、アカウント、ラベル、慣習を埋めるだけです。

準備ができたら、ここでリンクしますのでお待ちください。