summarization

要約

このスキルを使うと、AI エージェントは長文を明確で正確な要約にまとめられます。エージェントは、抜粋型（重要な文を原文のまま選択）、抽象型（新たな表現で書き換え）、階層型（詳細度の異なる段階的な要約）、複数文書型（複数の情報源を統合）など、複数の要約方法に対応しています。このスキルは、技術文書、議事録、研究論文、記事など、読者が全文を読まずに要点を把握したいあらゆるテキストを対象に設計されています。

ワークフロー

1. 入力を分析する： 原文の種類、長さ、構成を判断します。単一の文書か複数の文書か、見出しや章などの明確なセクションがあるか、または構成のない文章か、どの分野に属するかを特定します。これらをもとに、適用する要約方法を決定します。

2. 要約方法を選ぶ： 入力内容とユーザーのニーズに最適な方法を選びます。正確な表現が重要な事実文書や法律文書には、抜粋型の要約を使用します。読みやすさと簡潔さを優先する一般的な内容には、抽象型の要約を使用します。1 行の TLDR と詳細な内訳の両方が必要な場合は、階層型の要約を使用します。複数の入力を統合する場合は、複数文書型の要約を使用します。

3. 重要な情報を特定する： 要約方法にかかわらず、原文に含まれる主張、調査結果、決定事項、アクション項目、裏付けとなるデータの要点を特定します。文書内の位置（序論や結論は重要度が高い）、言及頻度、「重要なのは」「結論として」などの明示的な表現、ユーザーが示した目的との関連性を手がかりに、重要度の順に情報を整理します。

4. 要約を生成する： 指定された長さと詳細度で要約を作成します。事実の正確さを保ち、原文にない情報を決して加えないでください。原文の論理構造を維持します。階層型の要約では、3 つの段階を作成します。1 文の TLDR、短い段落（3～5 文）、セクションごとの詳細な内訳です。

5. 忠実さを確認する： 要約を原文と照らし合わせ、事実が歪められていないこと、重要な情報が抜けていないこと、原文にない内容が加えられていないことを確認します。数値データ、固有名詞、因果関係に関する主張が正確であることを確認します。

使用方法

要約するテキストをエージェントに渡し、必要に応じて、希望する長さ（1 文、短め、中程度、詳細）、要約方法（抜粋型、抽象型、階層型）、または特定の重点分野を指定します。

Summarize the following technical RFC into a short paragraph and a detailed
section-by-section breakdown. Focus on the proposed changes and their
backward-compatibility impact.

[paste RFC text here]

例

例 1：技術文書の階層的な要約

ユーザーのリクエスト：

この文書を、詳細度を変えて3段階で要約してください。

元の文書（一部）：

Kubernetes Gateway API は、Kubernetes でのサービスネットワーキングをモデル化するリソース群です。Ingress API の後継であり、より表現力豊かで拡張性が高く、役割指向のインターフェースを提供します。この API では、3つの主要なリソースタイプが導入されています。GatewayClass（共通の設定を持つ Gateway のセットを定義）、Gateway（クラスター内の Service にトラフィックを変換できるポイントを要求）、HTTPRoute（HTTP 固有のルーティングルールを定義）です。Ingress とは異なり、Gateway API はトラフィック分割、ヘッダー変更、クロスネームスペースルーティングをネイティブにサポートします。この API は、2023年10月にリリースされた v1.0.0 で GA になり、Istio、Envoy Gateway、Cilium、Traefik が実装を提供しています。Ingress からの移行は ingress2gateway ツールでサポートされていますが、複雑な設定については手動での確認が推奨されます。主な制限として、コア仕様では TCP/UDP ルーティングがサポートされていないこと（実験的なチャンネルの TCPRoute と UDPRoute で対応）や、実装ごとに成熟度が異なることが挙げられます。

出力：

要約（1文）： Kubernetes Gateway API は Ingress の GA 後継であり、より表現力豊かなサービスネットワーキングを実現する GatewayClass、Gateway、HTTPRoute リソースを導入し、トラフィック分割やクロスネームスペースルーティングをネイティブにサポートします。

短い要約（1段落）： 2023年10月に GA となった Kubernetes Gateway API は、Ingress API を、より表現力豊かで拡張性の高いサービスネットワーキングのアプローチに置き換えます。GatewayClass、Gateway、HTTPRoute という3つのコアリソースを導入し、役割（インフラストラクチャープロバイダー、クラスターオペレーター、アプリケーション開発者）ごとに関心事を分離します。この API は、トラフィック分割、ヘッダー変更、クロスネームスペースルーティングをネイティブにサポートします。これらの機能を Ingress で実現するには、アノテーションやカスタムリソースが必要でした。Istio、Envoy Gateway、Cilium、Traefik が実装を提供しています。ingress2gateway ツールを使って Ingress から移行できますが、TCP/UDP ルーティングは引き続き実験的であり、実装の成熟度にはばらつきがあります。

詳細な内訳：

• 概要： Ingress API の後継として設計された、サービスネットワーキングをモデル化する Kubernetes ネイティブのリソース群です。
• コアリソース： GatewayClass（共通の Gateway 設定）、Gateway（トラフィックの入口）、HTTPRoute（HTTP ルーティングルール）。
• Ingress からの主な改善点： トラフィック分割、ヘッダー変更、クロスネームスペースルーティング、役割に応じたリソースの分離をネイティブにサポートし、ベンダー固有のアノテーションが不要です。
• 現在のステータス： v1.0.0（2023年10月）から GA です。Istio、Envoy Gateway、Cilium、Traefik がサポートしています。
• 移行方法： ingress2gateway ツールで変換を自動化できますが、複雑な設定には手動での確認が必要です。
• 制限事項： TCP/UDP ルーティングは引き続き実験的です。プロバイダーによって実装の成熟度が異なります。

---

例 2：会議メモの複数文書要約

ユーザーの依頼：

次の3つの会議メモをまとめて、週次ダイジェストを作成してください。

元の文書：

月曜日のスタンドアップ（Team Alpha）：

v2.1 リリースのブロッカーである、決済処理のタイムアウト問題について話し合いました。Sarah が Stripe webhook handler の根本原因を調査しています。修正の予定日は水曜日です。Jake は新しいオンボーディングフローの UI を完成させ、コードレビュー中です。Maria は、ステージング環境の SSL 証明書が金曜日に期限切れになることを指摘しました。

水曜日のスプリントレビュー：

Sarah が決済タイムアウトを解決しました。根本原因は webhook handler にリトライ設定が欠けていたことでした。修正をステージング環境にデプロイしました。QA で正常に動作することを確認しました。Jake のオンボーディングフローの PR にアクセシビリティに関するフィードバックが寄せられ、対応中です。新しい項目として、プロダクトチームが v2.2 までにダークモードの切り替え機能を追加することを希望しています。見積もりは 3 ストーリーポイントです。

金曜日の振り返り：

チームは、今週は生産的だったと合意しました。決済の修正は予定どおりリリースされました。オンボーディングフローはアクセシビリティの修正後にマージされました。SSL 証明書は木曜日に Maria が更新しました。振り返りのフィードバック：証明書の期限切れに対するアラートを改善する必要があります。アクションアイテム：Maria が証明書の自動更新を監視する仕組みを設定します。今後の予定：ダークモード切り替え機能のデザインを月曜日に開始します。

統合した週次ダイジェスト：

2月10日〜14日の週 — Team Alpha ダイジェスト

リリース済み：

• 決済処理のタイムアウト修正 — 根本原因は Stripe webhook handler にリトライ設定が欠けていたことでした（Sarah）。水曜日にステージング環境へデプロイし、QA で確認済みです。
• 新しいオンボーディングフローの UI — Jake が完成させ、アクセシビリティに関するフィードバックを受けて更新し、金曜日にマージしました。
• ステージング環境の SSL 証明書を更新しました（Maria、木曜日）。

進行中：

• ダークモード切り替え機能を v2.2 のロードマップに追加しました（3 ストーリーポイント）。デザインは来週月曜日に開始します。

アクションアイテム：

• Maria：今後、期限切れの見落としを防ぐため、証明書の自動更新を監視する仕組みを設定します。

振り返りでの学び： チームは、証明書の期限切れに関するアラートがプロセス上の課題であると特定し、先手を打って対応しています。

ベストプラクティス

• 元の情報にない内容を追加しないでください。 要約は原文に忠実である必要があります。詳細が不確かな場合は、推測するのではなく省略してください。
• 数値の精度を保ってください。 元の文書に「37.5% increase」とある場合、要約でも「37.5% increase」とし、「nearly 40% increase」としないでください。
• 元の文書に合わせてトーンを調整してください。 法的契約の要約では正確で正式な表現が必要です。チームチャットのメッセージの要約なら、簡潔でくだけた表現にできます。
• 最も重要な情報を先に示してください。 要約を読む人は、内容をざっと確認することがよくあります。最初の文に重要なポイントを書き、その後に補足情報を加えてください。
• 長さの指定が曖昧な場合は、階層的なアプローチを使ってください。 ユーザーが長さを指定していない場合は、TLDR と段落程度の要約を提示し、好みの詳しさを選べるようにしてください。
• 複数文書の統合では、テーマに沿ってまとめてください。 各文書を個別に要約してつなぎ合わせるのではなく、文書にまたがるテーマを特定し、そのテーマを軸に統合した内容を構成してください。

エッジケース

• 非常に短いソーステキスト： 入力がすでに簡潔（100語未満）な場合は、これ以上要約すると重要なニュアンスが失われる可能性があることをユーザーに伝え、代わりに要点となる文を提示することを提案してください。
• ソーステキストに矛盾がある場合： 文書内に矛盾する記述がある場合は、どちらかを黙って選ぶのではなく、要約の中で矛盾を指摘してください。
• 高度に技術的、または専門用語が多いテキスト： 専門家ではない読者向けに要約する場合は、重要な用語を初出時に定義してください。専門家向けに要約する場合は、過度に簡略化せず、専門用語をそのまま使用してください。
• 不完全な文書、または途中で切れている文書： ソーステキストが途中で切れていると思われる場合（文の途中で終わっている、提供されていないセクションを参照しているなど）は、その旨を伝え、入手可能な内容のみを要約し、要約が不完全である可能性を指摘してください。
• 内容が重複する複数の文書： 複数の文書を要約する場合は、重複する情報を繰り返さずに整理してください。情報源の間で一致する点と異なる点を明記してください。