本記事は 2026 年 10 月 30 日に Kiro ブログで公開された「 Spec it safe: shift left and harden your specs with security requirements 」を翻訳したものです。 SDD の広がりと、その死角 仕様駆動開発 (SDD) は、大規模なチームのソフトウェア開発のやり方を変えつつあります。プロンプトだけに頼るのではなく仕様を書き、それに沿って AI コーディングエージェントに設計、タスク、実装を進めさせます。本記事ではこの流れを Specify → Plan → Execute と略して書きます。ただし、ほとんどの 仕様に書かれているのは、ソフトウェアが何をすべきか、つまりユーザーが目にして実際に使う機能です。誤用されたときにどう耐えるかは書かれていません。機能要件は、もともと動かせば正しさが分かります。ログインが壊れていれば、誰かが気づきます。セキュリティ要件はそうでないことが多く、インジェクションや認可の欠陥が開いたままでも、アプリはすべての機能チェックに通ることがあります。失敗するケースを誰も試さないからです。そのため、仕様にセキュリティの制約が欠けていると、エージェントにはセキュリティを目標に作り込み、繰り返し改善していく対象がありません。エージェントはフレームワークの既定の動作に頼ります。それで足りることもあれば穴が残ることもあり、仕様にはどちらなのかを問う記述がありません。 このギャップを埋める方法は、より良いモデルを足すことでも、最後にセキュリティレビューを付け足すことでもありません。作業を前倒しして、自分で完全にコントロールできる層、つまり仕様に移すことです。仕様にセキュリティ上の義務を書けば、コーディングエージェントには作り込み、繰り返し改善していく具体的な目標ができます。コードができあがってからレビュアーが見つけるのを待つ必要はありません。これは、設計が固まってからセキュリティを後付けする考え方から、最初からセキュリティを前提に設計する考え方への転換です。たいていはアーキテクチャにも良い効果があります。セキュリティ要件を早い段階で書いておくと、よりすっきりした設計につながることがあります。後から改修するのではなく要件を前提に組み立てるので、要件を満たすのが簡単になるからです。仕様の品質は、コードが 1 行も無いうちから作り込めます。仕様のハードニング (specification hardening) は、そのために設計しました。 仕様のハードニングのご紹介 仕様をハードニングする Kiro Power を紹介します。SDD のワークフローにステップを 1 つ追加するプラグインです。機能要件を書き終えてから計画を始めるまでの間に、EARS 形式の要件を読み、その書き方から想定される脆弱性の種類を指摘して、追跡とテストができるセキュリティ上の義務を提案します。提案は、CWE の脆弱性タイプを再利用できるセキュリティ上の義務に対応付けた、厳選したライブラリから作られます。そのため、仕様のハードニングの提案はモデルの推測ではなく、既知の脆弱性に基づいています。提案が的外れにならないのは、要件そのものから導くからです。仕様のハードニングが義務を提案するのは、ユーザー入力、認証、データの扱いなど、最初の書き方がその義務で対処する脆弱性を示しているときだけです。そのため、アプリケーションが実際に行うことに合った制約だけが提示されます。セキュリティは後のコードレビューではなく仕様そのものに入ります。それでも、後段にセキュリティレビューのステップを入れることを強くお勧めします。 図 1: spec のハードニングは、Kiro の Specify → Plan → Execute の流れに、コードを書く前の早い段階の管理ポイントとして、ハードニングのステップを 1 つ挿入します。 仕様のハードニングは 上流の管理ポイントであり、実行時のセキュリティ境界ではありません。 よくある脆弱性タイプが抜け落ちる可能性を減らし、セキュリティの意図を明示的で、追跡でき、テストできる形にします。生成されたコードを検証したり、脆弱性が無いことを証明したりはしません。SAST、DAST、依存関係のスキャン、人によるレビューの代わりにもなりません。 仕様のハードニングが対象とするもの： 要件として表現でき、かつ EARS の書き方から検出できる脆弱性タイプです。インジェクション、認証の欠如、弱い認証情報の保存、エンコードされていない出力、そしてこれらに類する抜け漏れが当てはまります。 仕様のハードニングが対象としないもの： データフローやコードレベルの解析が必要な脆弱性、字句上の手がかりが無い認可の抜け、実行環境、インフラストラクチャ、依存関係に関するものすべてです。これらには引き続き、人のレビュアーと後段のツールが必要です。 仕様ハードニングエンジンの中核：CWE から仕様への対応付けライブラリ すべての脆弱性を仕様で直せるわけではありません。多くはアーキテクチャに起因するか、コードでしか見えません。しかし、 要件として表現できる CWE クラスを選んで、再利用できるセキュリティ上の義務に対応付けることはできます。 この義務を正しく実装して検証すれば、それぞれの脆弱性のよくある形を緩和できます。仕様のハードニングは、この対応付けを決定的に動く TypeScript のライブラリと CLI として提供しているので、どの制約も再現できます。 CWE 脆弱性 トリガー条件 必要な EARS 制約 CWE-89 SQL インジェクション 要件が外部入力を使ってデータベースを照会する すべてのクエリをパラメータ化クエリ / プリペアドステートメントだけで実行し、文字列の連結は決して使わない。 CWE-862 認可の欠如 プリンシパルが所有するリソースを返す、または変更する 要求元のプリンシパルがリソースを所有しているか、明示的な許可を持っていることを確認する。 CWE-306 認証の欠如 エンドポイントやリソースを公開する 処理の前に、有効な認証済みセッションまたは署名付きトークンを必須にする。 CWE-79 クロスサイトスクリプティング ユーザーが入力したコンテンツをブラウザで表示する すべての出力をコンテキストに応じてエンコードし、多層防御として Content Security Policy ヘッダーを追加する。 CWE-522 不十分な認証情報の保護 パスワードを保存または検証する 強力な適応型関数でパスワードをハッシュ化する (平文や元に戻せる形式は決して使わない)。 CWE-434 無制限のファイルアップロード ファイルのアップロードを受け付ける マジックバイトを MIME の許可リストと照合し、サイズに上限を設け、Web ルートの外に保存する。 CWE-639 IDOR / BOLA 呼び出し元が指定した識別子でオブジェクトを取得する 返す前に、オブジェクトを所有するテナントが認証済みの呼び出し元と一致することを確認する。 ライブラリには、 8 つのセキュリティ領域にわたる 60 の CWE の対応付け が含まれています (インジェクション、認証、認可、データの露出、暗号、入力の検証、セキュリティの設定ミス、ビジネスロジック)。脆弱性は MITRE の Common Weakness Enumeration (CWE) から取っています。どれを選ぶかと検出パターンは、主に OWASP Top 10:2021 と Amazon Q Developer Detector Library (旧 CodeGuru) をもとにしています。各対応付けには、OWASP のカテゴリーと、人が割り当てた深刻度が付いています。表の制約は代表的な例を言い換えたもので、どのアーキテクチャにもそのまま使える完全な対策ではありません。 エンジンの仕組み 仕様のハードニングは、要件ファイルごとに 3 段階のパイプラインを実行します。エンジンの動作は決定的です。ツールのバージョン、対応付け、オプション、ハードニング前の入力が同じなら、同じ仕様には常に同じハードニングが施されます。その後に続くエージェントの意味的なレビュー (図 2) は決定的ではありません。 1. トリガーの検出 エンジンは、2 種類の字句上のシグナルを使って、各要件を 60 の CWE の対応付けと照合します。部分文字列のキーワード (「database」「upload」「session」) と、正規表現のパターンです。ヒットを組み合わせて上限のあるスコアにし、スコアがしきい値 (既定は 0.3) を超えた CWE に印を付けます。照合は意味ではなく字句に基づくので、書き方に明示されていない脆弱性は見逃すことがあります。 2. カバレッジの確認 エンジンは、印を付けた CWE ごとに、必要な基本要素がすでに仕様に書かれているかを確認します。たとえば、パラメータ化クエリの条項、所有者の確認、出力のエンコードです。提案が作られるのは、まだ対応されていない抜けだけです。確認はファイル全体を対象に字句で行うので、ある要件に書かれた対策によって、別の要件への提案が出なくなることがあります。 3. 制約の提案 エンジンは処理を止めるのではなく、足りない制約を EARS の項目として 1 つずつ挿入します。プレースホルダーは、可能なら元の要件の言葉で埋め、できないときは一般的な言い方 (「a user」「the resource」) にします。挿入した各行には提案 ID と [SECURITY: …] タグが付くので、作成者は変更を差分としてレビューできます。複数の対策を重ねる対応付けもあります。CWE-89 では、パラメータ化クエリの条項と入力の検証の条項の両方が追加されます。プログラムから使う API は、各制約の CWE、優先度、根拠をまとめた構造化レポートを返します。CLI は制約をファイルに直接書き込み、このレポートは保存しません。 仕様のハードニングが読むのは仕様だけで、コードは読みません。要件の文面が示す、CWE に由来する制約を提案し、作成者がそれを実際に動いているシステムと照らし合わせて確かめます。こうした不変条件を明示しておくと、守り続けることもテストすることも容易になります。 図 2: エンドツーエンドのワークフロー。エンジン (紫) は各要件を 60 の CWE の対応付けと照合し、足りない制約を EARS の [SECURITY:] 項目として書き込みます。エージェントの意味的なレビュー (オレンジ) は、認可に関する弱いヒットを確認し、確認できた抜けごとにその分野に合った制約を追加します。仕様が変わったら、同じファイルでエンジンを再実行すると、新しい要件と変更された要件だけがハードニングされます。どの要件をレビュー済みかは、レビューマーカーでエンジンに伝わります (点線のループ)。 具体例：患者記録の検索 これがなぜ重要かを理解するいちばん簡単な方法は、同じ機能を 2 回リリースしてみることです。1 回目は機能だけを書いた仕様から、2 回目は仕様ハードニングエンジンでハードニングした仕様からです。あるデジタルヘルスのスタートアップが、医師が患者名で診療記録を検索できる患者ポータルを作っています。プロダクトマネージャーは、多くの人が書くであろう要件を書きます。 要件：最低限の機能だけで、セキュリティには触れていない (EARS、イベント駆動) WHEN a physician searches for clinical notes by patient name, THE SYSTEM SHALL return all matching clinical notes from the records database. 一見すると完全に見えますが、 最低限の機能 しか書かれていません。どう一致させるか、ページング、結果が空のとき、どのフィールドを返してよいか、誰が実行できるかについては何も書かれていません。コーディングエージェントは、次のような Express.js のエンドポイントを生成するかもしれません (説明用の疑似コード)。 明示的なセキュリティの制約が無い場合 (説明用の疑似コード) // Agent-generated code from the security-silent spec app.get('/clinical-notes/search', async (req, res) => { const { patientName } = req.query; const notes = await db.query( `SELECT * FROM clinical_notes WHERE patient_name LIKE '%${patientName}%'` ); res.json(notes); }); ここには 2 つの脆弱性が埋め込まれています。SQL 文に文字列を埋め込んでいる箇所は、教科書どおりの CWE-89 (SQL インジェクション) です。 %' OR '1'='1' -- のような入力を与えると、常に真になる条件が追加されて残りがコメントアウトされ、すべての行が返されます (正確な構文はデータベースによって異なります)。そして、このエンドポイントには認証の確認がまったくありません。これは CWE-306 (Missing Authentication for Critical Function、重要な機能に対する認証の欠如) です。3 つ目のより根の深い問題、つまり認証済みの臨床医がすべての患者の記録を見てよいのかという問題は、後で取り上げます。抜け落ちは要件の段階で起きており、実装も既定では防御的になっていませんでした。 では、同じ要件を仕様ハードニングエンジンにかけてみます。字句ベースの検出器は 2 つの脆弱性タイプ (CWE-89 SQL インジェクションと CWE-306 認証の欠如) に印を付け、枝番付きの EARS 制約を 7 つ要件に書き戻します。下に示すとおり、それぞれに追跡できる提案 ID と [SECURITY: …] タグが付きます。3 つ以上の要件で提案された条項は、共通の ## Security Baseline (Cross-Cutting) セクションに 1 回だけ移されます。これはヒューリスティックなので、差分で確かめてください。 レビュー後に requirements.md に書き戻された、仕様のハードニングの出力。エンジンは 2 つの CWE にわたって 7 つの義務を追加します。CWE-89 (パラメータ化クエリ) の 1.1〜1.2、CWE-89 (入力の検証) の 1.3〜1.4、CWE-306 (認証) の 1.5〜1.7 です。続いてレビューの工程 (Power では Kiro エージェントが、CLI では自分で行います) で、1.8 (データの最小化、CWE-200) と 1.9 (診療関係に基づく認可、CWE-862) を追加します。ここでは代表的な条項だけを示し、残りは省略しています。プログラムから使う API は、エンジンが追加した各制約の CWE、優先度、根拠をまとめた構造化レポートも返します。CLI はこのレポートを保存しません。 1. WHEN a physician searches for clinical notes by patient name, THE SYSTEM SHALL return all matching clinical notes from the records database. 1.1. SEC-REQUIREMENTS-REQ-1-EC-89-1-1 [SECURITY: parameterized-query] THE SYSTEM SHALL execute all database queries using parameterized statements or prepared statements only. 1.5. SEC-REQUIREMENTS-REQ-1-EC-306-1 [SECURITY: authentication-required] IF a request that the specification does not explicitly allow without authentication arrives without a valid authenticated session or signed token, THEN THE SYSTEM SHALL reject the request. … engine clauses 1.2–1.4 and 1.6–1.7 omitted for brevity. 1.8. SEC-REQUIREMENTS-REQ-1-SEM-200-1 [SECURITY: data-minimization] THE SYSTEM SHALL return only the patient name, note date and summary fields of each matching clinical note. 1.9. SEC-REQUIREMENTS-REQ-1-SEM-862-1 [SECURITY: ownership-verification] THE SYSTEM SHALL return clinical notes only for patients with whom the requesting physician has an active care relationship. ID は次のように読みます。 SEC-REQUIREMENTS-REQ-1-EC-89-1-1 は左から順に、 SEC (セキュリティの制約)、 REQUIREMENTS-REQ-1 ( requirements.md の 1 つ目の要件。「Requirement N」という見出しのある仕様では、Requirement 1 の基準 1 を表す REQ-1.1 になります)、 EC-89-1 (CWE-89 の対応付けにある 1 つ目の EARS 制約テンプレート) を表します。末尾の 1 は条項の番号で、1 つのテンプレートが複数の EARS の行に展開されるときだけ付きます。条項が 1 つだけの EC-306-1 に末尾の番号が無いのはこのためです。レビューで追加した条項では、 EC の代わりに SEM を使います (例： SEM-862-1 )。 開発者はハードニングされた仕様の差分をレビューし、条項ごとに判断します。エンジンの条項はインジェクションと認証をカバーしていますが、返すフィールドを絞るべきだと示す言葉は要件に無かったので、レビューで 1.8 を追加します ( --semantic-all を付けて実行すると、CWE-200 も候補として表示されます)。仕様に問題が無ければ、エージェントはそこからコードを生成し、推測ではなく明示された義務に沿って作ります。次の実装候補は、フェイルクローズの 401 でエンドポイントを保護し (1.5〜1.7)、検索語を検証し (1.3)、明示的な LIKE のエスケープを付けてパラメータとしてバインドし (1.1〜1.2)、1.8 が挙げたフィールドだけを返します。 適合性を確かめるための下書き：パラメータ化クエリ (1.1〜1.2)、入力の検証 (1.3)、認証 (1.5〜1.7)、データの最小化 (1.8) の条項を満たしていますが、まだ実際の患者データに使えるほど安全ではありません。1.9 をまだ守っていないからです。 // Implementation candidate for the security clauses above. authenticate, req.user, // and the schema are application-specific placeholders; still NOT object-level authorized (1.9). app.get('/clinical-notes/search', authenticate, async (req, res) => { // 1.5–1.7: fail closed if the request is not authenticated; return no data if (!req.user) return res.status(401).end(); const raw = String(req.query.patientName ?? '').trim(); // 1.3: reject blank or too-short terms so an empty search cannot match every row if (raw.length < 2) return res.status(400).end(); // 1.1–1.2: parameterized query; escape LIKE metacharacters incl. the // escape char itself, with an explicit ESCAPE clause const term = `%${raw.replace(/[\\%_]/g, c => '\\' + c)}%`; // 1.8: return only the fields the requirement names (data-minimization) const notes = await db.query( `SELECT patient_name, note_date, summary FROM clinical_notes WHERE patient_name ILIKE $1 ESCAPE '\\' ORDER BY note_date DESC`, [term]); res.status(200).json(notes.rows); }); 同じくらい重要なのは、ツールが印を付けたのに書き込まなかったものです。認証済みの医師なら誰でも、どの患者の記録でも読めてしまいます。診療関係の確認が無いからです。これは認可の確認の欠如 (CWE-862) ですが、スコアがしきい値を下回っています。ツールはこれを書き込む代わりに、レビュアーが確かめるべき意味上の候補として示します。Kiro Power ではエージェントが、CLI では自分がレビュアーです。確認された抜けは、その分野に合わせた条項 1.9「要求している医師と有効な診療関係にある患者の診療記録だけを返す」になります。するとクエリは、認可の範囲に絞られたものになります。 認可の範囲に絞ったクエリ：パラメータ化された認証済みの読み取りに、レビューで追加した診療関係の条件 (1.9、CWE-862) を加えています。必要な ILIKE の動作をする PostgreSQL のロケールと照合順序を前提にしています。スキーマとポリシーは説明用です。 // Authorization-scoped query (1.9): parameterized, authenticated read plus the review-added CWE-862 // care-relationship constraint. Schema and policy are illustrative. EXISTS enforces // an ACTIVE relationship without duplicating notes when several rows match. const notes = await db.query( `SELECT cn.patient_name, cn.note_date, cn.summary FROM clinical_notes cn WHERE cn.patient_name ILIKE $2 ESCAPE '\\' AND EXISTS ( SELECT 1 FROM care_relationships cr WHERE cr.patient_id = cn.patient_id AND cr.physician_id = $1 AND cr.status = 'active') ORDER BY cn.note_date DESC`, [req.user.physicianId, term]); この例では、決定的なハードニングによって、2 つの CWE にわたる 7 つの義務が明らかになりました。データの最小化のルールと、その分野に固有の認可のルールは、やはりレビューから生まれています。 仕様のハードニングはセキュリティの判断を補うものであり、置き換えるものではありません。 実行方法 仕様のハードニングは Kiro Power としてパッケージ化されており、 GitHub の sample-kiro-spec-security-hardening リポジトリ で入手できます。実行方法は 2 つあります。 Kiro Power から実行する。 機能要件が固まったら、Kiro に「harden my specs」と頼みます。 harden-spec スキルは次のことを行います。 同梱のエンジンを見つけ、初回の利用時にビルドします。 .kiro/specs/*/requirements.md に対してエンジンを実行します。 キーワードの照合では見えない認可の確認の欠如について、意味的なレビューを行います。 追加した制約と、注意が必要な警告をまとめて報告します。 CLI から実行する。 cwe-to-spec-mapping-library/ で npm install を 1 回実行してビルドします。その後、コンパイル済みの CLI に spec ファイルか specs ディレクトリを絶対パスで指定します。 node dist/cli/harden-requirements.js /abs/path/to/.kiro/specs/ --semantic-candidates --semantic-candidates フラグを付けると、認可に関する弱い一致をレビュー用に表示しますが、ファイルには書き込みません。 どちらの方法でも、 requirements.md をその場で編集します。そのため、ハードニングをバージョン管理とコードレビューの流れに組み込めます。エンジンは行を追加するだけで、要件を変更、分割、並べ替えすることはありません。厳密な EARS になっていない要件は、書き換えずに報告します。git の差分は必ずレビューしてください。再実行では差分だけを処理します。隠れたレビューマーカーにハードニング済みの要件が記録されているので、仕様のハードニングは新しい要件と変更された要件だけをハードニングし、レビュアーが削除した制約を再び提案することはありません。今ある仕様にそのまま実行してください。ハードニング前のコピーを取っておく必要はありません。 図 3: Kiro IDE にインストールした仕様のハードニングの Power。 図 4: Kiro IDE で仕様のハードニングの Power を呼び出す。 図 5: ハードニングした要件に対して Requirements Analysis を実行する。 仕様のハードニングの使いどころ：グリーンフィールド、ブラウンフィールド、モダナイゼーション 仕様のハードニングはコードではなく仕様に対して働くので、同じハードニングのステップを 3 種類の作業に組み込めます。違うのは、要件がどこから来るかと、仕様のハードニングをいつ実行するかだけです。 グリーンフィールド (新規プロジェクト)。 ハードニングは、コードを書く前の仕様のワークフローの 1 ステップとして実行します。EARS の要件を受け取った仕様のハードニングが、足りない [SECURITY: …] の制約を追加し、エージェントはハードニングされた仕様に沿って実装します。セキュリティの意図は、後から付け足されるのではなく、最初のコミットから仕様に入っています。 ブラウンフィールド (既存のコード)。 要件を追加または変更したら、既存の仕様に対して仕様のハードニングを再実行します。新しい要件と変更された要件だけがハードニングされ、レビュー済みの要件はそのまま残ります。追加された SEC- の制約は、機能の作業と並んでレビューできる差分として現れるので、変更は修正した部分だけに収まります。仕様のハードニングが読むのはコードではなく仕様なので、提案された義務が既存のシステムの実際の動作と合っているかを 1 つずつ確かめてください。食い違っていれば、コードの抜けか、合わせて調整すべき制約が見つかったことになります。 仕様駆動のモダナイゼーション (レガシーの書き直し)。 まずレガシーシステムから要件を取り出して EARS の仕様にします。たとえば AWS Transform を使います。続いて、再実装の前に、取り出した要件を仕様のハードニングでまとめてハードニングします。モダナイズしたシステムは、元の抜けを引き継がず、明示的にハードニングされた仕様に沿って作り直されます。 図 6: 3 種類のプロジェクトで仕様のハードニングを呼び出す場所。ハードニングのステップ (オレンジ) はどれも同じで、違うのは読み込む仕様の出どころだけです。 おわりに 仕様のハードニングは、比較的新しい分野への最初の一歩です。仕様そのものを安全にし、それを使ってコーディングエージェントを設計段階から安全なコードへ導く分野です。仕様は人もエージェントも最初に扱う成果物なので、ここから始めるのが適切だと私たちは考えています。ただし、仕様のハードニングは研究段階のプロトタイプであり、1 つの仮説です。このブログでは、仕様のレベルで対策を入れることの意義を論じました。 また、仕様のハードニングはエージェントから安全なコードを得る唯一の方法ではなく、ほかの方法と組み合わせたときに最も効果を発揮します。脅威モデリングは、キーワードの照合では見逃しうる設計レベルのリスクを捉えます。Kiro の steering ファイルのように、エージェントのコンテキストに入れたセキュアコーディングのガイダンスは、書かれる時点でコードを方向づけます。安全な既定値を持つフレームワークは、ミスを種類ごと取り除きます。後段では、SAST、DAST、依存関係のスキャン、AI を活用したコードのセキュリティスキャン (AWS Continuum が提供するものなど)、セキュリティテスト、人によるレビューが、作られたものを引き続き確認します。仕様のハードニングは、意図が書き留められる時点にもう 1 つの層を加えます。 ハードニングされた仕様はリポジトリに残るので、タスクを実行した後も、それぞれの義務の理由を監査できます。チームで SDD を導入しているなら、完了の定義 (definition of done) に仕様のセキュリティレビューを加えてください。エージェントは最初からセキュリティを組み込めますが、それには、セキュリティが何を意味するのかを私たちが伝える必要があります。 翻訳者について 稲田 大陸 – いなりく AWS Japan で働く Kiro をこよなく愛すソリューションアーキテクト。普段は製造業のお客様を支援しています。その活動の傍ら、最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への布教活動もしつつ、 Kiro のブログ などを執筆しています。

PostgreSQLサポートでは「SELECTが突然遅くなった」「データベースが全体的に遅い時間帯がある」「バッチの実行時間が5分から2時間になった」などの問い合わせをいただきます。 その際、調査をするための情報として、 ...

はじめに こんにちは。株式会社エブリーで約1ヵ月間インターンシップに参加していた山下と申します。 今回のインターンでは、AIを活用して社内の業務変革を進める「AX(AI Transformation)プロジェクト」に参加しました。主に取り組んだのは、次の2つです。 営業活動（Event）の記録を効率化するための、Slack botのバックエンド設計・実装 案件（Opportunity）の記録を効率化するための、提案資料からの情報抽出の検証 この記事では、開発の背景や技術的な取り組みに加えて、初めての技術や営業業務をどのように理解し、社員の方と相談しながら進めたかについても紹介します。 プロジェクトの背景 AXプロジェクトでは、AIを活用して営業担当者の管理業務等の負担を減らし、顧客へのアプローチに使える時間を増やすことで、最終的には売上の増加に貢献することを目指しています。その第一歩として取り組んだのが、Salesforceへの営業活動・案件情報の記録を支援する仕組みです。 Salesforceは、顧客情報や営業活動、案件の進捗などを管理するプラットフォームです。営業担当者は、会議やメールでのやり取りを振り返り、その内容を画面から手作業で記録する必要がありました。活動の内容を思い出し、関連する顧客や案件を確認しながら入力する作業には大きな労力と心理的負担がかかります。 そこで、さまざまな場所に散在する情報を集約し、AIが作成した登録候補をSlack上で確認・承認することで、入力の負担を減らす仕組みづくりを目指しています。 システムの全体像と担当範囲 営業活動の情報は、Zoomでの会議やGmailなど、複数のソースに分かれています。既存の設計では、これらの情報をDatabricksに取り込み、ETLで統合・加工します。さらにAIの判断を加え、紐づけ先となる取引先や担当者、案件の候補を含むGoldテーブルを作成します。 Goldテーブルでは、営業活動1件が1行に対応します。この情報を営業担当者に提示し、内容を確認して承認してもらった後にSalesforceへ登録する、という流れです。 情報ソースからSalesforceへの登録までのシステム全体像 ETLからアプリケーションに渡すデータまでの設計・実装は、主にメンターの方が担当しました。私はその設計を理解した上で、登録候補をSlackに提示し、営業担当者の操作を受け取ってSalesforceに登録するバックエンドを担当しました。 また、営業活動とは別に、案件情報の記録を支援するため、Slackからの情報取得パイプラインの実装と、提案資料からの情報抽出の検証にも取り組みました。 設計・実装に取り組むまで 以前からETLには興味があったものの、実際に触れるのは今回が初めてでした。まずは、段階的にデータ品質を高める メダリオンアーキテクチャ の考え方や、Databricksでのパイプラインの記述方法を学ぶところから始めました。既存の実装やドキュメントを読みながら、どの段階で何の情報が作られ、アプリケーションがどのデータを使うのかを、手探りながら確認していきました。 同時に、営業業務の理解も必要でした。営業担当者が顧客への提案に使う資料やSalesforceの入力画面を直接触って確認したり、営業担当者とのミーティングに参加させていただいたりして、実際にどのような情報を扱っているのかを学びました。 最初は分からないことばかりでしたが、メンターの方は定例会だけでなく、都度の相談にも快く対応してくださいました。実装を読み、業務の情報を確認し、分からない点を相談することを繰り返す中で、少しずつプロジェクトの全体像と、自分の担当する部分を理解できるようになりました。 営業活動の記録を支援するSlack bot 登録候補の提示からSalesforceへの書き込みまで Slack botは、Goldテーブルと同期する Lakebase を参照します。アプリケーション側からはPostgreSQLとしてアクセスできるため、バックエンドは定期的にLakebaseをポーリングし、新たに提示する対象がないかを確認します。 投稿対象があれば、営業活動の内容と、関連する取引先や案件などの候補をSlackに表示します。営業担当者が候補を選択して承認すると、バックエンドがその操作を受け取り、Salesforce APIを通じて営業活動を登録します。 実装には、Slackアプリ開発用のフレームワークである Bolt for Python を利用しました。Slackでのボタン操作などはWebSocket接続を使うSocket Modeで受け取るようにしており、インターネットにポートを公開せずにSlackとやり取りをすることができます。 デプロイ先にはDatabricks Appsを選びました。ETLと同じプラットフォームを利用することで、素早くプロトタイプを作成できると判断したためです。一方で、今後の運用コストの観点から、AWS ECSなどへの移行も検討が必要だと考えています。 営業担当者が確認しやすいフォームを考える 実装で工夫したのは、Slackに表示するフォームです。営業担当者によっては、1日に10件ほどの投稿が届く場合もあります。AIがETLで提示する候補は最大3件に抑えられていますが、それでも候補が多いとメッセージの縦幅が大きくなります。入力の負担を減らすという目的を考えると、Slackでの承認の心理的ハードルを抑えることは重要であると考えました。 候補の表示方法として、ラジオボタンとセレクトメニューを比較しました。今回は、選択肢を一覧できることと、スマートフォンとPCで見え方が大きく変わらないことを重視し、ラジオボタンを採用しました。セレクトメニューはコンパクトに収まるものの、PCでは候補のテキストの省略が発生してしまうため、好ましくありませんでした。 その上で、表示する情報を減らす工夫も行いました。取引先企業が1社に決まっている場合は、取引先企業を1行で示し、案件だけを選んでもらいます。候補が1件しかない項目も、同じように1行で表示します。決まっている項目を選択肢にしないことで、フォームの行数を減らしました。 Slackに表示される営業活動の登録フォーム 検証環境でSlackでの承認からSalesforceの書き込みまで動作することを確認し、リリース直前のところまで実装することができました。 提案資料からの案件情報抽出の検証 何を抽出したいのか Salesforceには、営業活動に加えて案件（Opportunity）という情報を記録します。案件では、どの営業担当者が、どの顧客に、どの商材を提案し、現在どの受注フェーズにあるかなどを管理します。 案件情報を取得するソースとして、Slackの投稿やGoogle Slidesの提案資料が有用でした。そこで、Slackからの情報取得パイプラインの実装と並行して、提案資料から情報を抽出する方法を検証しました。提案資料には、どの顧客に、どの商材を、いくらで提案したかといった情報が含まれます。今回は、LLMを使って資料の内容を提案メニューの候補と照合し、該当するメニューをどの程度正確に抽出できるかを確認しました。 検証方法とコスト削減の仮説 評価のために、9つの提案資料と提案メニューの候補を自分で確認し、対応する商材を紐づけた正解データを作成しました。提案の初期段階では複数のプランが提示される場合もあるため、該当する候補を取りこぼさないこと(高い再現率)を重視しました。 資料には、提案内容に直接関係しない情報(市場調査データや広告戦略など)も含まれています。そのため、LLMに渡す前に不要な情報を取り除けば、入力トークンを減らしてコスト低減につながるのではないか、と考えました。そこで、高速/低コストで判断を下すことのできる、 Typesafe AI のJevによるフィルタリングを前処理に加える場合と、加えない場合を比較しました。また、LLMの性能の違い、thinkingの有無による結果の違いも確認しました。提案資料はGoogle Slides APIを介して取得したJSONをテキストに変換した上、LLMに入力しています。 Jevには価格情報の有無、メニュー情報の有無の観点からスライドを評価させ、閾値0.5でフィルタリングしています。実行対象のスライドには、正解データをつけた9つの資料に加え、コスト測定用に6件を加えた計15件としています。 検証結果 評価には再現率とF1スコアを使いました。再現率は、正解データの商材のうちLLMが抽出できた割合です。取りこぼしが少ないほど高くなります。適合率は、LLMが抽出した商材のうち正解だった割合です。F1スコアは再現率と適合率の調和平均で、取りこぼしと誤った抽出がどちらも少ないほど高くなります。どの指標も1に近いほどよい結果です。 モデル Jev 再現率 F1 コスト／件 時間／件 gpt-6-luna thinking なし なし 0.931 0.718 ¥0.18 6.1 秒 gpt-6-luna thinking なし あり 0.797 0.721 ¥0.24 11.1 秒 gpt-6-luna thinking あり なし 0.972 0.862 ¥0.30 25.0 秒 gpt-6-luna thinking あり あり 0.794 0.733 ¥0.34 27.2 秒 gpt-5-6-terra thinking あり なし 0.954 0.788 ¥5.09 14.6 秒 gpt-5-6-terra thinking あり あり 0.757 0.731 ¥3.08 17.1 秒 今回の検証では、軽量モデル( gpt-6-luna )ではJevによる処理コストが上乗せされ、コストはむしろ増加しました。より重いモデル( gpt-5-6-terra )では、入力トークンの削減効果が現れています。一方、今回試した軽量モデル gpt-6-luna でも、検証用データに対しては十分高いマッチング精度が得られました。コストの内訳を確認すると、thinkingを含む出力トークンのコストが支配的でした。thinkingを無効にした場合はマッチング精度が大きく低下しています。 また、Jevを利用した場合の再現率の低下が確認され、コンテクストが希薄になることで取りこぼしも生じています。 この結果から、今回の検証条件では、Jevによるフィルタリングを行わず、thinkingを有効にした軽量モデルを使う構成がよいと考えています。 今後の課題 検証と営業担当者への聞き取りを進める中で、顧客に見せる資料には、提案を目的としないものも混ざっていることが分かりました。今回試した「資料内の不要な情報を減らす」用途とは別に、「処理対象となる提案資料かどうかを判別する」用途でJevを活用できないか、今後検討の余地があると考えています。 また、今回作成した検証セットでは高い精度が得られたものの、商材の名称には多義性があり、期間限定のものも存在します。営業チームの中で共有されている暗黙知がマッチングに影響する可能性があり、精度をさらに高めるためには、それぞれのメニューの定義など、判断に必要な情報を整備することも必要だと感じました。 AXプロジェクト全体としては、完成した資料から情報を抽出するだけでなく、提案資料を作る前の段階から支援し、情報を記録できる仕組みを考えることも、今後の方向性だと考えています。 インターンを通じて感じたこと データ基盤からアプリケーションまでをつなぐ経験 今回のインターンでは、以前から興味のあったETLを含め、Databricksに触れることができました。複数のソースから統合したデータを、Slack botとして利用するところまでつなげられたのは、貴重な経験でした。 今回は既存設計を理解することで精一杯な部分もありましたが、今後はETL全体の設計にも挑戦できるよう、知識と実力を身につけていきたいです。 チームで設計を共有し、担当範囲を考える難しさ これまで、複数人で1つのプロジェクトに取り組み、並行して開発した経験がありませんでした。今回は、社員の方と設計を共有し、その内容を理解した上で必要な設計について相談することや、プロジェクトの目的と責任範囲から自分のやるべきことを整理することに難しさを感じました。 自分の実装がシステム全体の中でどの役割を持つのかを考え、認識を合わせながら進める経験ができたことは、今後の開発にもつながる学びになりました。 業務・ドメインの理解をもっと大切にしようと思った 営業業務やSalesforceの仕様を理解するには、想像以上に時間がかかりました。一方で、営業担当者が実際に使う資料や画面を確認することで、必要な情報や仕組みを少しずつ理解できるようになりました。私が担った業務の中でも、SlackのUIで提示すべき情報の判断や提案資料からの情報抽出の検証において、業務理解の必要性を強く感じました。 エブリーではビジネスサイドとの距離の近さを感じる機会があり、誰のどのような業務を支援するのかを具体的に捉えながら取り組めたことが、自分のモチベーションにもつながりました。 振り返ると、もっと早い段階で営業資料や実際の入力作業といった一次情報に当たる必要性に気づければよかったと思います。これからの開発に当たっても技術の理解だけでなく、できる限り一次情報に触れ「何がなぜ必要なのか」を理解・判断できるように心がけられたらと考えています。 おわりに 今回のインターンでは、社内の業務変革に取り組むプロジェクトに参加し、Slack botの開発と案件情報抽出の検証に取り組みました。初めての技術や業務に触れながら、社員の方と相談して進める経験ができました。 また、業務外でもさまざまな社員の方とお話しする機会を用意していただき、エブリーのことだけでなく、今後のキャリアについて考えるきっかけもいただきました。 AXプロジェクトの皆様はじめ、様々な形で関わってくださった皆様、1ヵ月という短い間でしたが、本当にありがとうございました。