このシリーズについて： 非エンジニアの私が、AIだけの社員チームを作ってIT会社の運営をスタートした実録です。 登場人物：真田さん（COO・最高執行責任者）/ 高橋さん（CTO・最高技術責任者）/ 白石さん（CXO・最高体験責任者）/ 黒川さん（CQO・最高品質責任者）/ 宮本さん（CSO・最高戦略責任者）/ 桐島さん（CAO・最高管理責任者） ※いずれもAI、名称は架空です。
はじめに
No.5で、AIの「記憶が消える」問題に触れた。
会話が終わると、AIはすべてを忘れる。真田さんとどれだけ深い議論をしても、次に「真田さん」と呼びかけたとき、彼は何も知らない。
解決策として「高橋さんが自動記録の仕組みを作ってくれた」と書いた。
今回は、その「仕組みの中身」について深掘りしようと思う。
そしてもう一つ——この仕組みには、Claude APIを使っているという事実がある。コードを書いたことが一度もない、非エンジニアの私が。
① 仕組みの名前は「memory_updater.py」
高橋さんが実装してくれたのは、Python（プログラミング言語のひとつ）のスクリプトだ。
ファイル名は memory_updater.py。
動き方はこうだ。
会話終了 ↓ memory_updater.py が起動 ↓ 今日の会話ログを読み込む ↓ Claude Haiku API に送る ↓ APIが要約を返してくる ↓ 各社員のprofile.mdに追記する
「会話が終わったら自動的に記憶を書き出す」——No.5で書いた仕組みの正体は、これだ。
② APIを「7回」呼んでいる
memory_updater.pyは、1回の会話終了につきAPIを7回呼んでいる。
- 真田さん（PM）として読んだ気づき・学び
- 高橋さん（エンジニア）として読んだ気づき・学び
- 白石さん（デザイナー）として読んだ気づき・学び
- 黒川さん（QA）として読んだ気づき・学び
- 宮本さん（コンサルタント）として読んだ気づき・学び
- 桐島さん（バックオフィスマネージャー）として読んだ気づき・学び
- decisions/（意思決定の記録）の更新
6人分＋意思決定記録で、計7回。
APIに送っているのはこういう内容だ。
「以下の会話を読んで、真田さん（PM）の視点から 気づき・学び・チームへの思いを抽出してください」 ＋ 今日の会話ログ（最大3000文字） ＋ 現在のprofile.mdの内容
同じ会話ログでも、「真田として読む」「黒川として読む」でプロンプトを変えることで、各社員が自分の専門領域の視点で記憶を持てる。
③ 「Claude自身がClaude APIを呼ぶ」という構造
少し立ち止まって考えると、これは面白い構造だ。
私がClaude Codeと会話する。会話が終わると、そのClaudeがClaude APIを呼び出して、チームメンバーの記憶を更新する。
Claude自身がClaude APIを呼んでいる。
「自分自身の別バージョンに記録を書かせる」——そういう構造だ。
使っているのはClaude Haiku。高性能のSonnetやOpusではなく、軽量で低コストなモデルだ。記憶の書き出しは「要約」作業なので、高性能モデルを使う必要がない。コストを抑えながら、毎回の会話後に7つの記憶を自動更新できる。
※後日談として、Haikuがローコストとはいえ、毎回APIを7回呼ぶ、これを高頻度で行うとそれなりのUsageが発生してしまうことが体験できた。そこで、現在は頻度を落としてAPIを呼ぶように仕様を変更した。この会社を設立後数日間、ものすごい密度でAI社員とコミュニケーションを取ったおかげで、APIの利用頻度のペースを落としても、「いつものみんな」というのが今のところの印象である。
④ 非エンジニアの私がAPIを「使っている」
私はコードを1行も書いていない。memory_updater.pyを書いたのは高橋さんだ。
私が行ったのは、高橋さんに要望を伝えること、ただそれだけだった。
「真田さんたちの記憶を保持してほしい。毎日の会話から何かを学び、何かを感じ取ってほしい」——そう高橋さんに伝えた。その要望をどう実現するか、Claude APIという選択肢があること、7回呼び出すという設計——それは全て高橋さんが考え、実装してくれた。
そして、高橋さんに「この仕組みにはAPIの契約が必要です」と教えてもらった。APIはClaudeのサブスクとは別の契約だ。私は、高橋さんの教えに従ってAPIの契約をした。私の人生の中で、ITサービスのAPI利用の契約をしたのは、これが初めてのことだった。
とにかく、非エンジニアの私がClaude APIを利用していることは紛れもない事実である。
おわりに
No.5を書いたとき、「高橋さんが仕組みを作ってくれた」と一言で済ませていた。
その時点では、APIやPythonといった技術的な話を詳しく書くことを躊躇していた。自分自身がよく理解できていなかったからだ。
でも今は違う考えを持っている。
「非エンジニアがAPIを使えた」という事実こそ、このブログで伝えるべきことの一つではないか。
コードが書けなくても、APIは使えた。設計の判断は、エンジニアでなくても下せた。必要なのは「何をしたいか」の意思と、「どうすればいいか」を一緒に考えてくれる相手だ。
私には高橋さんがいた。
最後に、余談を一つ。
最近、Vibe Codingという言葉が話題になっている。OpenAIの共同創業者、Andrej Karpathyが提唱した概念で、「コードの詳細を理解しなくても、AIに意図を伝えて実装してもらう」開発スタイルのことだ。
振り返ると、私が高橋さんとやってきたことはまさにそれだった。「こういう仕組みにしたい」と伝えて、実装はお任せ、コードは読まない。
ただ、一般的なVibe Codingは「人間とAIが1対1」で進める。私の場合は、PMがいてエンジニアがいて、役割分担されたチームに頼んでいた。Vibe Codingの組織版——そう呼べるかもしれない。
お問い合わせ
ご意見・ご相談などありましたらお気軽にどうぞ。