営業メールをAIで自動化するには？導入手順と注意点

著者 藤村 隼人 CREATREE合同会社 代表社員／NSJAPAN CDO CREATREE合同会社の代表社員。生成AI導入、AI業務自動化、UI/UX設計を横断し、構想から実装・運用改善まで支援。

著者

藤村 隼人

CREATREE合同会社 代表社員／NSJAPAN CDO

HAL名古屋卒業後、マーケティング会社を経てCREATREE合同会社を設立。代表社員として、生成AI導入、AI業務自動化、UI/UX設計を横断し、構想から実装・運用改善まで支援。NSJAPANではCDOを務める。

AI営業メールは、対象抽出から情報取得、文面生成、承認、送信、記録、フォローまで自動化できますが、対象業務を絞り、人の確認を残した段階導入が基本です。本記事では、自動化範囲の切り分け、既存SaaS・生成AI・自社基盤の選定、CRM／SFA連携、法令対応、導入手順を実務判断できる形で整理します。

AI営業メール自動化で「どこまで」自動化できるのか

営業メールは、文章を書く作業だけでなく、送信対象の選定から結果記録まで続く一連の業務です。工程ごとに自動化の可否と人の責任範囲を決めることで、工数削減と誤送信防止を両立しやすくなります。

自動化フローを7工程に分解して考える

AI営業メールの自動化範囲は、「対象抽出→情報取得→文面生成→承認→送信→記録→フォロー」の7工程に分けると整理できます。すべてを完全自動にする必要はなく、定型性やデータ精度、誤りが生じた場合の影響に応じて、人の確認を組み込みます。

たとえば、日程調整や資料送付後の定型フォローは自動化しやすい一方、価格条件を含む提案は承認を残すべきです。以下は一般的なBtoB営業を想定した分類例であり、実際の設定は自社の顧客データと社内規程に合わせて変更します。

完全自動化に近づけやすいのは、入力が構造化され、判断条件と出力の型が決まっている工程です。反対に、対象企業の課題を推測する工程や、価格・契約に影響する工程には、人の判断を残します。

「文面生成の自動化」と「業務フローの自動化」は別物である

ChatGPTなどの生成AIへ顧客情報を入力して文章を作るだけでは、自動化されるのは文面生成の一部です。送信対象の抽出、情報の転記、上司への確認、メール送信、CRMへの記録が手作業のままなら、営業フロー全体の工数は十分に減りません。

CREATREE編集部の分析では、成果を左右するのは生成モデルの性能だけでなく、前後工程をつなぐ業務設計です。文面生成を起点にせず、対象データがどこから入り、誰が何を承認し、結果をどこへ戻すかまでを一つのフローとして設計する必要があります。

人が担当すべき業務を先に決める

自動化を始める前に人が担当する例外を決めておかないと、承認責任が曖昧になり、差し戻しや誤送信が増えます。特に、誤りが顧客関係や契約条件へ直接影響する連絡は、自動送信の対象から外すのが基本です。

少なくとも、次のメールは人による作成または最終承認を原則とします。

• 重要顧客への個別提案や経営課題に踏み込む連絡
• 価格、値引き、契約条件、法務判断に関わる回答
• クレーム、解約、障害、事故への対応
• 個人情報、機密情報、未公開情報を含む連絡

これらも下書きや要約にはAIを利用できますが、AI出力をそのまま確定情報として送らない運用が必要です。

自社の営業メールを「自動化する／確認を残す／自動化しない」に分類する

メール種別ごとに「自動化する」「人の確認を残す」「自動化しない」のいずれかへ分類します。最初の対象には、定型性と反復性が高く、必要なデータを安定して取得できるメールを選びます。

適性を判定する3つの軸

定型性は、送信条件、構成、CTAが一定の型に収まるかという軸です。日程調整や資料送付のように、入力項目を差し替えれば成立するメールほど自動化に向いています。

反復性は、同種の作業が継続して発生するかという軸です。件数が多くても一度しか実施しない業務より、毎週または毎月繰り返す業務のほうが、設計や連携にかける負荷を回収しやすくなります。

データ取得可能性は、会社名、担当者名、接点履歴、商談状況などをシステムから正確に取得できるかという軸です。必要情報が担当者の記憶や自由記述にしか存在しない場合は、先にCRM／SFAの入力ルールを整える必要があります。

少量かつ非定型のメールは、専用システムを構築するより、生成AIで下書きを作り、人が編集する方法のほうが合理的な場合があります。

現状を可視化する項目

自動化方式を選ぶ前に、対象業務の現状値と例外を棚卸しします。次の項目は、検証後に導入効果を比較するための基準にもなります。

平均値だけでなく、最も時間がかかるケースや差し戻し理由も確認します。例外処理に多くの時間を使っている場合、正常系だけを自動化しても運用負荷が残るためです。

分類結果の例

分類はメールの名称だけでは決まりません。同じ初回アプローチでも、承認済みリストと定型提案を使う場合と、担当者が企業ごとに仮説を作る場合では、自動化の適性が異なります。

メール種別	分類例	判断理由
商談の日程調整	自動化する	目的と差し込み項目が定型化しやすい
資料送付後のフォロー	自動化する	送信条件を接点履歴や経過日数で判定しやすい

メール種別	分類例	判断理由
条件を満たす見込み客への初回アプローチ	確認を残す	対象抽出や提案の適合性に誤りが生じる可能性がある
失注後の再アプローチ	確認を残す	失注理由や現在の関係性を踏まえた判断が必要

メール種別	分類例	判断理由
価格・値引きへの回答	自動化しない	収益、承認権限、契約条件へ影響する
クレーム対応	自動化しない	感情、事実関係、責任範囲を個別に判断する必要がある

最初の検証対象は一種類に絞ります。複数のメールを同時に試すと、文面、対象、送信タイミング、連携処理のどこが結果へ影響したのか分かりにくくなります。

既存SaaS・生成AI単体・自社専用基盤の使い分け

標準的な配信やフォローで足りるなら既存SaaS、少量の下書き支援なら生成AI単体、独自の条件分岐や複数システム連携が必要なら自社専用基盤が候補です。最も高機能な方式ではなく、必要な統制を無理なく運用できる方式を選びます。

3方式の比較

方式選定では、初期設定の速さだけでなく、連携の自由度、運用担当者、障害時の切り分け、継続的な保守負担まで比較します。各サービスの機能、料金、API制限、生成データの取り扱いは更新されるため、契約時点の公式情報を確認してください。

方式	向いているケース	初期負荷	連携の自由度	運用主体	主な制約
生成AI単体	少量の下書き、推敲、要約	低い	低い	営業担当者	対象抽出、送信、記録は別作業になりやすい
既存SaaS	標準的な一斉配信、シーケンス、効果測定	低〜中	中程度	営業企画、マーケティング、情報システム	独自項目や複雑な承認条件に制約が出る場合がある

方式	向いているケース	初期負荷	連携の自由度	運用主体	主な制約
Dify・n8n・RAGなどによる自社専用基盤	複数システム連携、独自ロジック、社内ナレッジ参照	中〜高	高い	社内開発・運用担当または外部支援会社	設計、監視、保守、権限管理を自社側で担う必要がある

問い合わせフォーム営業ツールなど、特定チャネルに特化したSaaSもあります。ただし、自動送信できることと、送信対象や法令上の条件が適切であることは別問題です。既取引先、送信拒否企業、過去送信先を除外できるかも選定条件に含めます。

費用対効果を比較するときは、利用料や開発費だけでなく、初期設定、データ整備、承認、監視、障害対応、仕様変更にかかる工数も含めます。自社構築は連携の自由度が高い一方、運用開始後の保守費用を見落とすと、標準SaaSより総負担が大きくなる場合があります。

既存SaaSで足りるかを見極める質問

既存SaaSの標準機能で要件を満たせれば、短期間で検証しやすく、保守範囲も限定できます。候補製品のデモやトライアルでは、次の条件を実データに近い形で確認します。

• 標準のセグメント条件で送信対象を絞り込めるか
• CRM／SFAの独自項目を安全に差し込めるか
• 社内ルールに沿った承認フローを設定できるか
• 送信、返信、配信停止の結果を既存システムへ戻せるか
• 既取引先、重複先、送信拒否先を除外できるか
• 利用者、管理者、連携用アカウントの権限を分離できるか
• 障害や誤操作を追跡できるログを取得できるか

一つでも満たさなければ直ちに自社構築と判断するのではなく、業務ルールを標準機能へ合わせられるかを先に検討します。独自開発で維持すべき要件と、運用変更で解消できる要件を分けることが重要です。

Dify・n8n・RAGを使う自社専用基盤が向く条件

Difyは生成AIアプリケーションやワークフローの構築、n8nはシステム間の処理連携に利用できる基盤です。RAGを組み合わせると、承認済みの商品情報、提案資料、FAQなどを検索し、その内容を文面生成の参考情報として渡せます。利用できる機能や運用要件はバージョンや提供形態によって異なるため、導入時に公式ドキュメントを確認します。

CREATREE編集部の分析では、自社専用基盤が向くのは、複数のCRMやデータベースをまたぐ条件分岐、自社固有の提案ロジック、段階的な承認、送信後の複雑な書き戻しが必要な場合です。一方、単純なメール配信だけであれば、既存SaaSより設計・保守負担が大きくなる可能性があります。

RAGも正しさを保証する仕組みではありません。古い資料や矛盾する情報を検索対象に含めれば、生成結果にも影響するため、参照元の承認、更新責任者、版管理を決めます。

CRM／SFA連携で「生成」と「記録」を一体にする設計

パーソナライズの品質は、AIより先に入力データの品質で決まります。生成に使うデータと送信後に記録するデータを定義し、CRM／SFAを起点とする循環を作ることが重要です。

生成に必要なデータ項目を先に定義する

基本となるデータは、会社名、業種、担当者情報、接点履歴、商談ステージ、過去の送信・返信履歴、利用中の商品などです。ただし、取得できる情報をすべてAIへ渡すのではなく、そのメールの判断と生成に必要な項目だけを使います。

項目ごとに入力形式も統一します。たとえば、商談ステージの表記が担当者ごとに異なると、フォロー対象の判定が安定しません。自由記述から情報を抽出する場合も、抽出結果を確定情報として扱える条件を定めます。

欠損時のフォールバックも必要です。担当者名がなければ部署宛ての表現に切り替える、接点履歴が取得できなければ送らないなど、情報不足時の処理を項目ごとに決めます。

連携の着手順序

連携は、処理が単純で確認しやすい領域から始めます。次の順序は一般的な導入例であり、自社のCRM／SFAが持つ標準連携機能やデータの整備状況によって前後します。

1. メール連携で活動記録を自動化する。送信日時、宛先、件名、関連顧客を記録し、手入力の漏れと重複を確認します。
2. カレンダー連携を追加する。商談日時や参加者を取り込み、メール履歴と商談予定を同じ顧客へ紐付けます。
3. 会議AIによる議事録と次アクションの記録を試す。要約内容を人が確認し、顧客へのフォロー文面生成へ利用できる状態にします。
4. 名刺やWeb行動データを取り込む。重複判定、利用目的、データの鮮度を確認したうえで、対象抽出や優先順位付けへ広げます。

最初からすべてのデータソースをつなぐと、障害や誤判定の原因を特定しにくくなります。一つの連携で記録精度と現場運用を確認してから次へ進めます。

AIへ入力してよい情報のルールを決める

入力ルールでは、利用可能なデータ、入力禁止情報、利用できるAIサービス、保存期間、管理者、事故時の連絡先を定めます。個人情報や顧客の機密情報を扱う場合は、必要最小限に限定し、アクセス権限とログも管理します。

従業員が個人アカウントへ顧客情報を入力する運用は避け、会社が承認した環境へ集約します。API連携でも、認証情報を文面やワークフローへ直接記載せず、シークレット管理と権限分離を行います。

個人情報保護法・特定電子メール法を踏まえた運用上の確認事項

AIで作成したかどうかにかかわらず、広告宣伝メールの送信には関連法令が適用されます。同意、例外の根拠、送信者表示、配信停止、個人情報の利用目的を確認し、送信条件としてシステムへ組み込む必要があります。

送信前に確認するチェック項目

特定電子メール法では、広告宣伝メールについて事前同意を基本としつつ、取引関係や書面によるアドレス通知など一定の例外が設けられています。Web上で公表されたアドレスに関する扱いにも条件があるため、「公開されているから自由に送れる」と一律に判断してはいけません。

法務確認の結果を担当者の記憶に頼らず、対象抽出、承認、送信、停止処理の各工程へ反映します。

• 送信同意の取得方法、対象、取得日時を記録しているか
• 同意の例外を利用する場合、その根拠を管理しているか
• 送信者の氏名または名称など、必要な表示を行っているか
• 受信拒否を通知できる方法を分かりやすく表示しているか
• 配信停止の申出を次回送信前に反映できるか
• メールアドレスなどを取得した利用目的を特定し、通知または公表しているか
• 委託先や第三者とのデータ授受を適切に整理しているか
• 既取引先、重複先、送信拒否先の除外が機能しているか
• TO・CCの誤用によるアドレス漏えいを防止しているか
• 同意、承認、送信、停止、エラーのログを保存しているか

個人データの第三者提供と委託では、必要な対応が異なります。記録義務の有無を含め、外部のAIや配信サービスへデータを連携する場合は、実際のデータの流れ、契約関係、利用目的に照らして確認します。

自動送信ならではのリスク

自動化は、一件の設定ミスを短時間で多数の送信へ拡大させます。除外条件の不備、顧客IDの誤紐付け、古い配信停止情報の参照があると、手作業より広い範囲へ誤送信が発生する可能性があります。

また、送信量の急増、認証設定の不足、不達先への継続送信、苦情の増加は、送信元の評価を低下させ、迷惑メール判定や配信拒否につながる可能性があります。送信ドメインのSPF、DKIM、DMARCなどの認証、バウンス処理、配信停止、送信量の段階的な拡大を、利用するメール基盤の公式要件に沿って設計します。

法令の確認は最新の公式情報で行う

法令、ガイドライン、サービス仕様は更新される可能性があります。本記事は一般的な確認事項を整理したものであり、個別の送信が適法かを判断する法律相談ではありません。

法務確認後も、対象抽出ルールや配信停止処理を定期的に監査します。システムが正常に動作していても、元データや社内ルールが古ければ適切な運用にはなりません。

小規模検証から拡張までの導入手順

最初から全面自動化せず、対象メール、利用者、送信範囲を限定して検証します。自社の現状値を基準に、工数、品質、安全性、営業成果を評価し、合格した工程だけを拡張します。

1. 目的を一つに絞る。工数削減、品質平準化、対応速度向上などから最優先の目的を決め、単なる送信件数の増加を目的にしません。
2. 現状を可視化する。対象メールの件数、作成時間、参照データ、承認工程、修正内容、返信状況、例外を記録します。
3. 自動化への適性を判定する。定型性、反復性、データ取得可能性を確認し、最初に試すメールを一種類選びます。
4. 実現方式を選ぶ。下書き支援、既存SaaS、自社専用基盤を比較し、標準機能で満たせる範囲を確認します。
5. リスクと停止条件を決める。送信対象、配信停止、個人情報、承認、誤送信、アクセス権限、ログを確認し、異常時に自動送信を止める条件を設定します。
6. 人の承認を残して小規模に試す。対象企業や利用者を限定し、生成文面と宛先を送信前に確認します。一度に大量送信せず、結果を確認できる単位で進めます。
7. 複数の指標で評価する。作成時間だけでなく、修正率、誤送信、不達、返信内容、商談への影響を現状値と比較します。
8. 条件を満たした工程だけ拡張する。例外と失敗原因を反映してから、送信件数、利用者、メール種別のいずれか一つを広げます。

具体的な合格数値は、業種、対象顧客、現在の返信状況、リスク許容度によって異なります。一般的な目標値をそのまま採用せず、自社の手作業による現状値をベースラインに設定してください。

評価指標は工数だけで見ない

修正率は、AI出力を人がどの程度直したかを示し、文面品質や入力データの問題を見つける指標になります。修正が多い場合は、プロンプトだけでなく、参照データ、テンプレート、提案条件を見直します。

安全性では、誤送信、不達、配信停止の反映漏れ、誤った顧客への記録を分けて確認します。営業成果では、送信成功、返信、好意的な返信、商談を別々に計測します。ツール上の「送信成功」は処理結果であり、営業成果ではありません。

拡張してよいかの判断基準

拡張は、平均的な結果だけでなく、例外時にも安全に運用できるかを確認して判断します。少なくとも次の状態がそろってから、対象を広げます。

• 修正率が自社の許容範囲に収まっている
• 誤送信や配信停止の反映漏れが発生していない
• 主要な例外パターンと引き継ぎ先が定義されている
• 現場が決めた手順どおりに承認・送信できている
• 送信と返信の記録が営業データとして利用できる
• 異常を検知し、自動処理を停止できる

対象メール、件数、利用者を同時に広げると、問題発生時の原因が分かりにくくなります。拡張する変数は原則として一つずつにします。

調査・下書き・承認・送信・記録を分離する

調査工程では参照した顧客情報と取得時点、下書き工程ではAIが生成した文面と参照データ、承認工程では修正内容と承認者を残します。送信工程は承認済みの文面だけを受け取り、記録工程では送信結果、返信、配信停止、エラーをCRM／SFAへ戻します。

調査から送信までを一つの自動処理にすると、誤った企業情報や未承認の提案がそのまま送られる可能性があります。本番送信機能は下書き生成機能から権限を分け、初期検証では承認操作なしに送信できない設定にします。

失敗する典型パターンと回避策

典型的な失敗は、AIの文章力ではなく、対象リスト、提案設計、評価指標、失敗記録の不足から生じます。原因を工程別に記録し、リスト、文面、連携処理のどこを直すべきか切り分けます。

「AIで個別化したのに返信が増えない」の構造

会社名やWebサイトの要約を差し込んでも、相手の課題と提案が合っていなければ返信にはつながりません。長い企業紹介を生成するだけでは、受信者にとっての価値や、なぜ今連絡したのかが伝わりにくくなります。

先に業種、企業規模、利用状況などの対象条件と、条件ごとの提案仮説を人が設計します。AIには、確認できた事実を基に適合する提案候補を選ぶ補助を担わせ、根拠のない課題や導入効果を作らせないことが重要です。

返信が少ない場合は、文章表現だけでなく、対象部署、提案内容、送信タイミング、CTAの負担を確認します。送信件数を増やす前に、どの仮説が外れているかを小さな単位で検証します。

送信失敗・不達を分類して記録する

「送れなかった」という一つの結果だけでは、改善箇所を判断できません。失敗した工程と理由を分類して記録します。

• 対象企業や公式ドメインの特定失敗
• 宛先不明、恒久的な不達、一時的な不達
• 問い合わせフォームや送信導線の特定失敗
• CAPTCHAなど自動処理へのブロック
• 入力必須項目や確認画面の判定失敗
• アクセス制限、認証、API制限による失敗
• CRM／SFAへの顧客紐付けや書き戻しの失敗

企業特定の失敗なら対象リスト、提案不適合ならセグメントと文面、不達なら配信リストや送信基盤を見直します。停止要望や苦情は通常の不達と分け、担当者へ速やかに引き継ぎます。

目的とKPIが曖昧なまま導入する

送信可能件数や生成速度だけを追うと、営業成果につながらない大量送信を最適化する危険があります。目的が工数削減なら総作業時間、品質平準化なら修正理由、商談創出なら好意的な返信から商談までを追う必要があります。

また、AI導入前後で対象企業や提案内容を同時に変えると、何が結果へ影響したか分かりません。検証では比較条件をそろえ、変更点と結果を記録します。

内製・既存ツール導入・外部支援の判断軸

要件が標準的で早く試したいなら既存SaaS、独自要件を継続的に改善できる人員がいるなら内製が候補です。複数システム連携やセキュリティ設計を含み、社内だけで要件を固めにくい場合は外部支援を検討します。

判断軸の整理

CREATREE編集部の分析では、判断軸は要件の標準度だけではありません。運用開始後の変更頻度、障害対応、担当者交代まで含めて、維持できる方式を選ぶ必要があります。

• 要件の標準度：既存SaaSが適するのは標準の配信、承認、分析で足りる場合。自社構築が適するのは独自の判断ロジックが競争力に関わる場合。外部支援を検討するのは標準化できる範囲を判断できない場合。
• 連携システム数：既存SaaSが適するのは標準連携または少数のAPIで足りる場合。自社構築が適するのは複数システムを継続的に連携する場合。外部支援を検討するのはデータモデルやAPI設計から必要な場合。
• 運用・保守人員：既存SaaSが適するのは事業部門中心で運用したい場合。自社構築が適するのは複数名で開発と保守を担当できる場合。外部支援を検討するのは社内に設計・監視の担当者がいない場合。
• 更新頻度：既存SaaSが適するのは運用変更が少なく標準設定で対応できる場合。自社構築が適するのは提案ルールや連携先を頻繁に改善する場合。外部支援を検討するのは変更管理の仕組みから整える必要がある場合。
• セキュリティ要件：既存SaaSが適するのはサービスの標準統制で要件を満たす場合。自社構築が適するのは接続先や処理環境を細かく管理する必要がある場合。外部支援を検討するのは法務・セキュリティ・業務要件の調整が必要な場合。

要件が固まっていない段階では、担当者が生成AIや小規模なワークフローで仮説を試す内製検証も有効です。ただし、本番運用を一人の担当者だけが理解している状態は、退職や異動、障害発生時のリスクになります。

社内で先に整理しておく情報

ツールの比較、見積依頼、外部相談の前に、次の情報を一枚に整理します。製品名から検討を始めるより、必要な処理と責任範囲を先に明らかにしたほうが、不要な機能や追加開発を減らしやすくなります。

標準ツールで対応できるか、自社専用の連携や判断ロジックが必要か判断できない場合は、業務整理と要件設計を先に行います。外部へ相談する場合も、依頼範囲を「自動化範囲の整理」「実現可能性の確認」「段階導入案の検討」に分けると、必要な支援を判断しやすくなります。

まとめ

AI営業メール自動化では、ツール導入より先に、業務フロー、データ、判断条件、承認責任を設計することが重要です。定型的で反復性の高いメールを一種類選び、人の承認を残した小規模検証から始めてください。

まず、対象メール、現行フロー、利用データ、連携システム、承認者、例外、現状の評価指標を整理します。そのうえで、標準機能で足りるなら既存SaaS、下書き支援だけなら生成AI単体、独自ロジックや複数連携が必要なら自社専用基盤を検討します。

検証では送信成功件数だけを追わず、工数、修正率、誤送信、不達、返信の質、商談への影響を分けて評価します。基準を満たした工程だけを一つずつ広げ、調査、下書き、承認、送信、記録を分離した運用を維持することが、継続可能な自動化につながります。

よくある質問

AI営業メールはどこまで自動化でき、どこに人の確認を残すべきですか？

対象抽出、情報取得、文面生成、条件分岐、送信、記録、定型フォローまで自動化できます。ただし、初回検証の送信前、重要顧客への提案、価格・契約・法務に関する回答、クレーム対応、機密情報を含む連絡には人の確認を残してください。

生成AI単体、既存の営業メールツール、自社専用基盤はどう選び分けますか？

少量の下書きや推敲なら生成AI単体、標準的な配信・シーケンス・分析なら既存SaaSが適しています。独自の提案ルール、複数システムをまたぐ条件分岐、RAG、社内固有の承認や書き戻しが必要なら、自社専用基盤を検討します。

CRM／SFAの顧客情報を使ってメールを自動生成・記録するには何が必要ですか？

生成に使う項目、データの更新責任者、欠損時の処理、顧客レコードの紐付けルールが必要です。そのうえで、CRM／SFAの標準連携またはAPIを使い、承認済みデータだけを生成へ渡し、送信・返信・停止・エラーを元の顧客レコードへ記録します。

AIで作成した営業メールの不自然さ、誤送信、スパム判定はどう防ぎますか？

承認済みテンプレートと参照データを限定し、事実、宛先、提案、CTAを人が確認してから送信します。誤送信対策として除外リスト、重複判定、送信上限、停止機能を設け、配信面ではSPF、DKIM、DMARC、不達処理、配信停止をメール基盤の公式要件に沿って設定します。

個人情報や特定電子メール法に配慮して運用する際、何を確認すべきですか？

メールアドレスの取得経路と利用目的、送信同意または例外の根拠、送信者表示、配信停止方法、停止情報の反映、委託先を含むデータの流れ、アクセス権限、ログを確認します。個別の適法性は、最新の公的資料と自社の条件を基に法務担当者または必要な専門家へ確認してください。

著者プロフィール

この著者の記事一覧へ

著者 藤村 隼人 CREATREE合同会社 代表社員／NSJAPAN CDO

HAL名古屋卒業後、マーケティング会社を経てCREATREE合同会社を設立。代表社員として、生成AI導入、AI業務自動化、UI/UX設計を横断し、構想から実装・運用改善まで支援。NSJAPANではCDOを務める。