第一章では、会話や日記に含まれるつながりを、あとから経路と元の記録ごと取り出したい、と考えた。
では、その記録はどこから入ってくるのか。
最初から営業議事録を扱う業務システムを作るのは難しい。そこで自宅では、もっと小さく、身近なアプリを土台にする。候補は二つある。
- 短い文章を投稿し、他の投稿と反応を残すSNS投稿アプリ
- 自分の文章を日付付きで残し、あとから振り返る個人ログアプリ
見た目は違うが、バックエンドから見ると、どちらも「記録を登録し、その記録に含まれる人・話題・出来事を、あとで関係づけて検索するアプリ」である。
アプリを先に置く理由
知識グラフだけを作ろうとすると、最初に「どんなノードが必要か」「どんな関係を定義するか」を考え続けることになる。それでは、実際に誰が何を入力し、何を見たいのかが分かりにくい。
投稿アプリなら、入口と出口を先に決められる。
投稿する
↓
記録として保存する
↓
関連する投稿・人・話題とつなぐ
↓
投稿の背景や経路をたどる
↓
次の投稿、相談、企画の材料にする
個人ログアプリなら、次の流れになる。
今日の記録を書く
↓
日付・テーマ・出来事と一緒に保存する
↓
過去の記録とつなぐ
↓
困ったこと・試したこと・分かったことをたどる
↓
振り返りや記事の材料にする
この二つの画面を同時に作る必要はない。まずどちらか一方のアプリを作り、内部の記録形式を共通にできるかを見る。
SNS投稿アプリとして考える
架空の投稿を三つ登録する。
| 投稿ID | 投稿者 | 内容 |
|---|---|---|
| post-01 | アキ | 日記を整理する小さなプログラムを作ってみたい。 |
| post-02 | ミナ | 日記整理ツールをPythonで作った。 |
| post-03 | ミナ | 日記整理ツールの作り方なら紹介できる。 |
投稿画面で必要なのは、まず文章を入力して保存することだけである。投稿した時点で、完璧なグラフを作る必要はない。
バックエンドでは、投稿を元の記録として保存する。
{
"record_id": "post-01",
"record_type": "post",
"author_id": "user-aki",
"text": "日記を整理する小さなプログラムを作ってみたい。",
"created_at": "2026-09-20T10:00:00+09:00"
}
投稿から関係を作った場合も、投稿そのものを置き換えない。投稿は根拠として残し、そこから得たノードや関係を別に持つ。
投稿 post-01
└─ アキ --取り組みたい--> 日記の整理
投稿 post-02
├─ ミナ --作った--> 日記整理ツール
└─ 日記整理ツール --目的--> 日記の整理
投稿 post-03
└─ ミナ --紹介できる--> 日記整理ツール
この構造があれば、「日記の整理に取り組みたい人」と「日記整理ツールを作った人」を、投稿をまたいで探せる。
個人ログアプリとして考える
同じバックエンドに、個人ログを登録することもできる。
{
"record_id": "log-01",
"record_type": "personal_log",
"author_id": "self",
"text": "日記から過去の判断理由を探したが、見つけにくかった。",
"created_at": "2026-09-20T22:00:00+09:00"
}
続けて、次の記録を追加する。
log-01: 日記から過去の判断理由を探しにくかった。
log-02: 日付とテーマを付けて探せるようにした。
log-03: 先月の判断理由を見つけやすくなった。
この場合、グラフは次のような流れになる。
困ったこと
↓ きっかけ
日付とテーマを付ける
↓ 試した結果
判断理由を見つけやすくなった
投稿者が一人でも、記録の間には関係がある。人間関係のグラフだけが知識グラフではない。個人の経験、試行、結果をつないだグラフも、外部記憶として使える。
SNSと個人ログで共通にするデータ
アプリの表面は、投稿か個人ログかを選べるようにする。一方、共通バックエンドでは、記録を次のように扱う。
| データ | 役割 |
|---|---|
record |
投稿や個人ログの原文を保存する |
actor |
投稿者や記録の主体を表す |
concept |
Python、日記の整理、判断理由などの話題を表す |
event |
作った、試した、困ったなどの出来事を表す |
relation |
ノード間のつながりと、その根拠の記録IDを持つ |
重要なのは、relationだけを保存しないことである。
relation: ミナ --紹介できる--> 日記整理ツール
source: post-03
このように元の投稿へ戻れれば、グラフが作った要約だけを信じる必要がない。あとで投稿を訂正したときも、どの関係を見直すべきか分かる。
アプリから見たい画面
SNS投稿アプリの最初の画面は、普通の投稿一覧でよい。そこに、投稿を起点にした「つながりを見る」を加える。
投稿 post-01
日記を整理する小さなプログラムを作ってみたい。
[つながりを見る]
関連する人: ミナ
経路: アキ -> 日記の整理 <- 日記整理ツール <- ミナ
根拠: post-01, post-02, post-03
個人ログアプリでは、個別の記録から過去の経路を開く。
log-03
先月の判断理由を見つけやすくなった。
[経路を見る]
困ったこと -> 日付とテーマを付ける -> 見つけやすくなった
根拠: log-01, log-02, log-03
この画面で、LLMが作った説明だけを表示するのではなく、ノード・関係・根拠の記録を表示できるようにする。自然文の説明は、その後に追加できる。
第二章で作る範囲
ここで作るのは、会社の営業議事録システムではない。自宅で動かす、小さな投稿または個人ログのアプリである。
第一段階では、次の機能に絞る。
- 投稿または個人ログを登録できる。
- 原文、投稿者、日時、記録種別を保存できる。
- 記録から作られたノードと関係を、元の記録に結びつけられる。
- 記録を起点に、関連ノードと経路を表示できる。
- 経路上の関係ごとに、根拠の原文へ戻れる。
ログイン、複雑な通知、公開範囲の細かな設定、完全な推薦機能は、この検証の中心ではない。ただし、SNS形式を選ぶ場合は、公開範囲を無視して個人ログを混ぜない。個人ログ形式を選ぶ場合も、将来ほかの記録種別を追加できるように記録種別を持たせる。
会社業務との関係
最終的に想定しているのは、会社の営業議事録からナレッジグラフを作り、顧客・課題・提案・対応履歴の関係をたどれるナレッジデータベースである。
しかし、会社業務のデータや固有の議事録を自宅プロジェクトへ持ち込むわけではない。会社で実装する前に、公開可能な架空の投稿や自分の個人ログを使って、次の共通部分を検証する。
SNS投稿 / 個人ログ
-> 原文を保存する
-> 記録を構造化する
-> 関係と根拠を蓄積する
-> ノード間の経路を検索する
-> 結果をアプリで表示する
営業議事録の場合も、入力が営業記録に変わるだけで、中心となる流れは同じになる。
営業議事録
-> 顧客・課題・提案・対応を記録する
-> 関係と根拠を蓄積する
-> 顧客の課題から過去の提案や対応をたどる
この類似性を確かめるために自宅で実装する。会社への導入、業務データの利用、会社の採用判断は、このQiita記事の範囲外である。
まとめ
第二章の題材は、SNS投稿アプリでも個人ログアプリでもよい。大事なのは、アプリの見た目ではなく、登録した記録を共通のバックエンドへ渡し、記録同士の関係と根拠をあとからたどれることだ。
自宅では身近なデータで試す。Qiitaでは架空のデータと公開可能な実装だけを書く。その結果を、会社の営業議事録ナレッジグラフにそのまま適用できるとは言わない。
次は、どちらか一方のアプリを小さく作り、記録の登録から経路表示までを通す。