0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

エージェントAI時代の営業スタイル:ディレクトリ構成で考えるナレッジ管理

0
Posted at

はじめに

私はこれまでアプリケーション開発に携わり、今年から営業を担当するようになりました。その中で、「開発で当たり前にやっていた情報整理の考え方は、営業にも応用できるのではないか?」と考えるようになりました。

現在は所属組織の環境において、IBMのコーディングアシスタントAIである「IBM Bob」なども活用しながら、情報整理の方法を工夫しています。

まだ試行錯誤の途中ではありますが、

営業活動を構造化して扱うことで、AIの活用がしやすくなるのではないか

と感じているため、その考え方を共有できればと思います。


営業を「アプリケーション」として捉える考え方

一つの整理の仕方として、営業活動をアプリケーションに見立てると理解しやすくなります。

ソフトウェア 営業
データ 顧客情報
ライブラリ 製品情報・業界知識
フレームワーク 営業手法・提案プロセス
ロジック 提案内容の組み立て
入出力 商談・資料

このように考えると、営業も「入力された情報をもとに、何らかの判断をしてアウトプットするシステム」として捉えられます。

この整理は、AIに文脈を与える際にも役立つと感じています。


ディレクトリ構成で整理する例

私自身は、サンプルですが、考え方としては以下のようなディレクトリ構成で情報を整理しています。

/sales-app
├── customers/        # 顧客情報
├── products/         # 自社製品情報
├── frameworks/       # 営業フレームワーク
├── playbooks/        # 実践ガイド
├── knowledge/        # 業界・競合情報
├── logs/             # 商談ログ
└── proposals/        # 提案資料

それぞれの役割はシンプルです。

  • customers/
    顧客ごとの情報や履歴

  • products/
    製品情報(資料をMarkdown化)

  • frameworks/
    提案やヒアリングの進め方

  • playbooks/
    コミュニケーションや実践ノウハウ

  • knowledge/
    業界やトレンド

  • logs/
    商談内容の記録


実際の運用イメージ

いくつかの具体例です。

顧客情報の整理

  • 公開情報(Web、ニュース)
  • 実際の会話内容
  • AIによる要約

これらを顧客ごとにまとめています。


製品情報のMarkdown化

資料(PowerPointやPDF)を、そのまま使うのではなく、

👉 Markdown形式に整理

しています。

これにより、AIが扱いやすくなると感じています。


商談ログの蓄積

TeamsのトランスクリプトなどをAIで要約し、

logs/2026-05-10.md

のように保存しています。

これが後の振り返りや文脈理解に役立つ場面があります。


社内ナレッジの活用

研修資料や営業の考え方もMarkdown化しています。

例えば:

playbooks/executive-communication.md

この状態にすると、AIに対して

自社の考え方を踏まえた提案を考えて

といった形で依頼しやすくなります。


AIの活用イメージ

このように整理しておくと、AIは以下のような情報を参照できます。

  1. 顧客情報
  2. 商談履歴
  3. 営業フレームワーク
  4. 製品情報

その結果として、

👉 次にどう動くべきかのヒントを得やすくなる

と感じています。

コード生成における補完のように、

👉 営業活動の補助的な役割

として使える可能性があるのではないかと考えています。


Markdownで整理する意味

Markdownを使っている理由はシンプルです。

  • 構造がある
  • 軽量で扱いやすい
  • 人にもAIにも読みやすい
  • ファイル単位で管理できる

特別なツールに依存せずに運用できる点もメリットです。


Kubernetesとの類似点(個人的な感覚)

少し大げさかもしれませんが、この考え方はKubernetesの思想にも少し似ていると感じています。

Kubernetesでは:

  • YAMLで状態を定義
  • アプリとインフラをまとめて扱う

一方で、営業ナレッジでは:

  • Markdownで情報を整理
  • 顧客・製品・戦略を同一の構造で扱う

👉 異なる要素を「同じ形式で扱う」ことで整理しやすくなる

という点で、共通する部分があるように思います。


組織で活用する場合の気づき

個人レベルでは進めやすい一方で、もし組織で広げる場合は課題もありそうです。

特に感じているのは、

ナレッジの鮮度を誰が担保するか

という点です。

例えば:

  • 製品情報
  • 営業フレームワーク
  • 研修資料

といったものは、個人任せにするとばらつきが出やすいです。

そのため、

👉 企業側が主体的に更新・管理する仕組みがあった方が良いのではないか

と感じています。

こうした基盤が整うことで、

  • 情報のばらつきが減る
  • AIの出力が安定する
  • 全体の底上げにつながる

可能性があるのではないかと考えています。


エージェントAI時代に向けて

これからのAIは、単純な質問応答だけでなく、

👉 コンテキストを踏まえた支援

が期待されていると思います。

そのためには、

  • 情報が整理されていること
  • 継続的に更新されていること
  • 文脈がつながっていること

が重要になってきます。

今回紹介したような方法は、その一つのアプローチになるかもしれません。


さいごに

営業という仕事は、これまで個人の経験やスキルに依存する部分が大きかったと思います。

その中で、

  • 情報を構造化する
  • Markdownで整理する
  • AIに活用しやすい形にする

といった取り組みは、

👉 営業の進め方を見直す一つのヒントになるのではないか

と感じています。また、これは営業に限らず、様々な情報をインプットに判断する管理職の人たちにも使えるアイデアではないかと考えています。

まだ試行錯誤の段階ではありますが、
同じようにAI活用を模索されている方の参考になれば幸いです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?