1. となりのデータ分析屋さん
  2. 183. 日々の行動をログとして..
183. 日々の行動をログとして残す意識!ログの残らない仕事は排除するのだ!
2026-09-02 18:27

183. 日々の行動をログとして残す意識!ログの残らない仕事は排除するのだ!

感想

まだ感想はありません。最初の1件を書きましょう!

サマリー

本エピソードでは、過去の業務ログや会話履歴をGBrainに入力することで、AIが過去の情報を参照し、より的確な回答やタスク実行を可能にするという体験が語られます。モデルの進化に任せるのではなく、自身の知識や判断材料を蓄積することの重要性が再認識されます。また、チームでのGBrain活用における情報管理や権限設定の課題、そしてAIが読みやすいマークダウン形式での情報蓄積の有効性についても議論されています。

GBrainへのログ入力と過去情報の活用
ジーブレイを入れるにあたって、やりたいことは仕事のことと自分の今までの得た気づきとか学びとか、日々のログみたいなところを、たまたまこうオブシディアンを使って日々の業務ログみたいなのを取ってたんですよ、マークダウンの形で。
4月に復帰して、そこから今8月、4ヶ月とか5ヶ月のログがあったんで、それを全部ジーブレイに入力として入れて、GitHubのリポジトリも入れて、今までクロードコードとかコーデックスで会話してたセッションのログ、
あれも全部テキストというかファイルとして管理されてるんで、それも全部入れると、仕事でやってたことが全部ジーブレイのインプットとして入れることができたんで。
なので、それを入れて入れ終わったときに、じゃあ明日のトゥードゥとか仕事の中で詳細のことを質問すると、すぐジーブレイにMCV経由で情報アクセスして探してくれて、全部回答してくれるようになったんで、そういう意味だと過去の情報をちゃんと残しておくことって大事だったんだなっていうのは、もうダイレクトに気づけたんでよかったですね。
知識蓄積の重要性とモデル進化
そうなんだよね。結構ぶち込んでるね。いいな。
1年前とか1年半前ぐらいに、たぶんポッドキャストでも話してるんだけど、モデルはどうせ勝手に進化するから、ナレッジとか手元に残せる知識とか、そういう判断材料をどれだけため込むかが本質だろうって言ってたのが、
マジでこのぐらいで伏線回収されてきてる感じがめちゃめちゃするんだよね。確かにそうかも。本当にモデルが進化していくのは任せててよかった1年半だったみたいな。そこを追うよりも、やっぱり自分の持ってる情報を整理していくってところの価値の方が圧倒的に大きいなっていうのは思いますね。
それはね、めちゃめちゃある。でもセッション全部残してるはいいな。俺なんか爆発するなと思って結構丸めた情報しか残してないんだよ。
なるほど。ただでもデフォルトで1ヶ月とかセッションの回数か、ちょっとここ曖昧ですけど、それぞれのコーディングエージェントは持ってるんで、キャッシュとかをクリアしない限りは一定直近は残ってるはずですよ。だからそれをまず入れてみるはありですね。
でも残ってるから、残した設定がそのスキルがいろんな更新のされ方をして果たしてそれを残してくれてるかが不安だって感じだな。
そうですね。
セッションログの管理と抽象化
なんかセッションっていうフォルダーにずっと溜まるようにした記憶はある?
結構そのコーディングエージェントと対話していく中での気づきとか、自分なりの癖とか、そこにだけ入れてる情報ってあるんで。
そうなんだよね。
定期的にセッションで残すか、一旦こうまとめたファイルとして別に置いとくかはやっておいた方がいいかもしれないですね。
残ってるかな、残ってるはず。記憶はある。毎回選んだよ。逆に言うと俺全セッションでメモリーとクロードMDとのスキルのレビュー毎回回すから。
じゃあまあ抽象化されてるけどそっち側に情報が蓄積されてはいますよね。
そう。で時系列的になんかもう使われてないメモリーとかがだんだん削られるように作ってあって。
だからなんか俺はそれを毎回回すから、そのスキルのクオリティちゃんと磨き込まないとみたいな言ってるやつにすげー反論したくなっちゃうんだよね。
どうせそのスキルをずっと使うんだったら、どっかに収束、ある程度実用的なレベルに収束するようにAI、クロードとかを使うようにしてるから。
常に洗練してるんですね。
けどなんか機械学習の頃で言うとこの短期記憶重視ではあるね。だからLSTMのLを落としてる可能性が今出てきてる。
ロングの方ね。ロングタームを残さないとやっぱりっていうのはあるかもしれない。
確かにロングタームを残すためのなんかあってるな。あの図覚えてるわ。
あのウィンドウをいつの間にか消失した可能性があるな。残ってたら神だな。
GitHub連携とGBrainの個人研究
そうですね。生データじゃなくてもそういうものはGitHubとかに上げておいて、
常に最悪ログを辿れば見れるみたいな状態にしておくのも大事だなと思っていて。
そうだね、確かにね。
Gbrainもローカルで管理ができるけど、抽象化したデータはちゃんとGitHubのリポジトリとして残すような設定もできたりするんで。
確かにね。
そういう連携も大事だなと思って。
結構ここ1週間とかはGbrainの個人的研究を進めてうまく使っていきたいなっていうことになりましたね。おすすめ。
ログの重要性と日報の役割
早くちょっと会社の設定見直したいな。
自分もこれからだなと思うんですけど、あれが構えてると、ちゃんとログを残そうという気持ちが強まるようになりますね。ログの重要性。
ここに来て日報とかちゃんと書こうっていう風になってきてますもんね。
でもね、どうなんだろうね。
俺は逆に日報はセッション前振り返りでいいだろう派なんだよね。
いいと思う、それでも。
今までは日報をちゃんと書いておこうっていう、トゥードゥとやったことみたいな、出したやることくらいはまとめておこうだったんですけど、
このGbrainになった瞬間に、もう使うUIはクロードコードとかコーデックスとかそういうコーディングエージェントだけで完結するから、それがすごい便利。
一挙一動すべてをモニタログに残されてほしいっていう。
そういう意味では中国の監視社会はあながち悪でもないかもしれない。
フィジカルデータも取れるからね。
それはめちゃめちゃ思ってるから、それが結構いい。
GBrainの進化とデータベース構築
でもGbrainもね、多分もう俺が軽く使ってる状態より、この1週間、2週間だいぶ巻かれてる気がするから、今の聞いてる人。
これからだなと思うけど。
あとはデータベース自分でちゃんと作んないとまずいぜっていう指揮位置を超えるまでため込みたいよね。
そうですね。
ローカルでまかなえるくらいでやれる範囲はやりきりたいし。
LLM API接続とベクトル検索の課題
2つ課題があって、1つはLLMのAPIをつなぐってところを今やってなくて。
じゃあサーチの方法がだいぶ弱め?
サーチというかベクトル空間に落とすができてないんですね。
そうだね。
なのでキーワード検索だけが今使える状態になっていて、ベクトル検索しようと思うと、
LLMのAPIをつなぐか、もしくはローカルにLLMをモデルを置いて、それで動かすっていう二択になるんですけど、
どうしてもちょっと会社のセキュリティとかの関係でAPIをすぐ使える状況にないんで、
そうなるとローカルのLLMをまず使ってみようかなっていう話とかあったり、
チーム利用における課題と情報コントロール
あとさっきチームで使ってみようが次のステップになってくるんですけど、
そうなった時にユースケースとして、
マネージャーが例えばこのチームの今週のアクションというか実績をまとめてみたいな、
そういうユースケースが実現できるようにしたいんですね。
チーム利用した時に。
来週のアクションどうなってるみたいな、いわゆる進捗管理ができるようになるみたいなところ。
でも見せたい情報と見せたくない情報ってメンバーレベルだとあるじゃないですか。
なるほどね。
そこをどう色付けするかみたいなところが結構チーム利用でディスカッションした時に、
分かりやすく課題というか、これから解決しなきゃいけないところだなというふうに出てきていて、
じゃあ情報のインプットをどうやってコントロールするかっていう話が難しいなっていう。
それはね、むずいな絶対に。
そうなんですよね。
っていうのが結局それが個人に紐づいて、
個人がジーブレに入れる情報をどうやってコントロールしようかなみたいな判断の話になってくるんで、
それが使っていく中の今後の課題になりそうだなというふうに思ってますね。
GBrainの限界と今後の発展性
それが多分さっき言ってた権限管理につながるような気もするんだよね。
そうだね、確かに。
見られたくないもそうだし、見せたくないもそうだしみたいな。
両方あるんだよ多分。
おそらくジーブレの限界はそこにあって、
OSSなんでそこからさらに使いやすくしていく度にはこれをフォークして自前でアプリケーション化していくっていうところに
本格的に使うのであれば作っていくことになるのかなとは思いますけど。
そうね、だから多分あれが正解ではないんだよね。
正解ではないというか、現時点の結構最先端の使い方というか、しっくりくるとこまでは到達できるんだけど、
ここからどうなっていくかみたいな。
そうですね、だって多分みんな使ってる人たち同じような課題感絶対抱えてるわけだから、
チーブ利用に特化した新しいものが出てきたりとか、
っていう方向かなと思っておりますね。
チーム内ルール作りと個人運用の重要性
それもさっきのLLMのモデルのクオリティみたいな話と一緒で、
ツール面がどうなっていくかみたいなところは自分で寄せていくプラス、
私は1週間以内ぐらいにまたすごいの出てくるから。
はいはい、確かに。
じゃあ逆にどうやって情報を見せる見せないを考えるかをチームの中でルール作りをしていく方が、
もしかしたらやるべきことかもしれないですよね。
か、とりあえずそこは考えずに、
いかにログを漏らさない個人の運用を全員に浸透させておけるかみたいな。
あーそうだね、確かに。
そのぐらいがまだ正解なのかもしれない。
みんながジブリンをまず個人で使えるレベルにしておくとかそういうこと。
そうそうそうそう。
マークダウン形式とAIの読みやすさ
結局はそれが蓄えられていれば後々料理するのは簡単だからみたいな。
そうだね。
最近ベクトル空間に落とす方じゃなくて、
マークダウンの保存の仕方、見出しがついてて、
あれさ、1年半前に自分がいたアナリティクス組織のナレッジを貯めるときの
マークダウンの中の作り方が結構あれに近い形で元々作ってて、
AIが呼び出しやすいような見出し付けというか、
ちゃんと一個のファイルの中がストーリーになって、
ボリューミーなところもちゃんと残ってるしみたいな書き方になってて、
勘どころ意外と良かったんだ俺みたいな。
このフォーマットに落としておけばAIは読みやすいっていう俺の感覚ベースで
あのファイルの形に似たのを作ってて、
あれをツールの中身を見たときに感動した。
方針間違ってなかったんだみたいな。
それをさらにベクトル空間に生んぬみたいな発想までは持ててなかったけど。
なるほどね。
それを蓄積していればまんまGブレインに入れられたし。
そうそう。可能性はあったなと思って。
AIが読みやすいマークダウンの構造化
情報として何かを残すときとかに、
AIが読みやすいフォーマットっていうのが決まってたりするんですか?
多分あれは一個の型としてこういう風に俺らは埋めるよみたいな
Gブレインの中のファイルの書き方みたいなのが定義されてるじゃん。
なんとなくマークダウンがAIにとって読みやすいんだみたいな風潮が世の中にあったときに
アナリティクスのナレッジをため込む方法だから
SQLとかをどう正解をAIに覚えさせるかみたいなところで
結構正解のSQLをどんどん溜め込むっていう方向でみんな言ってたんだけど
そうじゃなくて周辺のコンテキストまで全部一個のマークダウンに
レポートみたいな感じで書くみたいな形にしてたのね。
背景にはこういうのがあってみたいな。
この分析とこの分析が関連してるから共通のIDみたいなのも振ってあって
こういう背景こういう依頼の文面があった上でSQLはこれだった
その後レポートにこうやって使ったみたいな
一個のマークダウンで綺麗に構造化されて
ストーリーが書かれてるような管理の仕方にしてた。
それがまあまあ聞いてたんだよね。
コンテキストウィンドウが狭いタイミングですら。
でももっと溜め込んでもうちょっと繋がりを工夫しないと
SQL書いた後にその数字を見た時の解釈までAIにさせるのは
むずいよなって思いながらその形で埋めてたんだよね。
それを作ってチームみんなこの形で格納してほしいっていうので
全員に言っててみたいな。
半分正解半分寄せ方を教えてもらったみたいな。
マークダウン主義からHTMLへの移行
確かにあったよね。マークダウン絶対主義みたいな。
期間がありましたよね。間違ってはいないんだけどね。
それの中の構造をどんだけ工夫してるかみたいな
チームでナレッジとして蓄積するために
どういう風に足並みを揃えるかみたいなところを
AIに相談しても正解が出ない時代に
ただひたすら頭で考えて手でテンプレートを作ってた形にちょっと似てて
それがでももう今になったら
AIが勝手にその形に落としてくれるようになってきているっていうのも
また面白いところですよね。
試行錯誤とツールの進化
まだいいのを搭載できてるギリギリって思って
自分がね。
頑張りすらももうAIがやってくれるってなってくることを考えると
追いつき追い越されてる感じはありますよね。
まあそうだよね。そりゃそうって感じ。
さっき話してたようなエッチ運転みたいな話も
そこであのタイミングで疑問に思ってたのは
素晴らしいことだったんだって半年後ぐらいに思いたい。
でもどんな状況でも
これってどうしたらいいんだろうみたいな考えて
アクションしておくみたいなことはやっぱ大事かなと思っていて
時間が経った後に
同じようなことが当たり前になってくるわけじゃないですか
今回のマークダウンの形式もそうですけど
そうなった時に
じゃあやっぱこのフォーマットで中身は整理されてるんだなっていうところの
ツールの理解とかが一気に進むから
全く考えないはやっぱ違うなと思っていて
常にもっと良くしたいなみたいなところで
試行錯誤はしていきたいなとは思っていますね。
原始的な考え方と
ディスカッションとツールのスタンダード化
意外と紙とペンを持って考えている時間が大事だと思う。
チームリオの話をさっきした時に
やっぱ結局ツールでいつかは
それがスタンダードになるからっていうのも分かりつつ
やっぱりディスカッションは続けると思うんですよね。
もっとこうしたいよねとか
ああいう形がいいよねとかっていう
おそらくそれがもうツール側で
すべて整理されて
世の中に出てくるっていうのが
すぐ来るんだろうなっていうのを期待したいですね。
エンディング
全然話ちょっと飛ぶんだけどさ。
マークダウン市場主義だったじゃんみたいなところからさ
今HTMLの方がいい説みたいなの出てるじゃん。
出てますね。
なんかしてる?
じゃあ終わります。
隣のデータ分析屋さん今回も面白いと思ったら
フォロー・レビューよろしくお願いします。
番組の感想や質問は
ハッシュタグ隣の分析屋
隣のがひらがなで分析屋は漢字でお願いします。
また概要欄に貼ってあるお手紙フォローから
コメントお寄せください。
ではまた。
バイバーイ。
18:27

コメント

スクロール