これまでにカンファレンスなどで発表した資料をここにまとめます。 随時更新です。
最終更新: 2025-01-18
↓↓↓ 発表日降順で並んでいます
続きを読む春先のミカンへ
2025年3月、我が家にミカンの木がやってきた。 福岡市の都心の森１万本プロジェクトで苗木が無料でもらえたのだ。
が、鉢底の排水穴が詰まったまま雨ざらしにしていたので梅雨の時期に完全に水没してしまった。 これまで葉が一枚また一枚と落ちていたから変だなと思ったんだよね。
鉢が水に浸かってしまうと根が空気を吸えずに窒息して弱ってしまう。 根は幹を支えて水を吸い上げる役割だが、空気にふれて呼吸もしなければ生きられない。
これではいけないと思って慌てて水を抜いた。 しばらく日陰で土をかわかして、その後は数週間に一度だけ計画的に水をあげることにした。
すると翌月には体力を取り戻して新芽が出始めた。
たったの10日ほどで新しい枝が伸びてきた。成長速度がすごい。
2025年9月頃、初めは黄緑だった新しい枝はすっかり新緑になった。
さらに1ヶ月ほど経って10月、また新芽が出てきた。暑い夏をこえて成長の秋が来た。
ところが、
新しく出た葉にウネウネの模様が出てしまった。 夏のあいだにエカキムシ(ハモグリガ)の卵が葉の裏に産み付けられていて、幼虫が葉を食べすすめて成長するらしい。なんと。
葉が食べられて歪になってしまったが、栄養を蓄えるのに葉は必要なので切らずに残すことにした。
そして冬を越した。
2026年3月、そろそろ春である。また新芽が出ることを期待しつつ、虫に食べられないように先手を打つ。
まずは肥料をあげる。 この肥料、800ml入りで使うときは5000倍希釈だ。余裕で30年分ある。
そして支柱を立ててアミをかけた。 このアミは日光はほとんど通しつつ虫の侵入を防いでくれる。
春先のミカンへ、どうかすこやかに育ってほしい。
BigQueryの課金モデルを見直してコスト削減した
GA4 のイベントデータを BigQuery にエクスポートして分析しています。
1日あたりのデータは数GB程度なんですが、毎日蓄積されつづけるのでコストが気になりますね。
なので課金モデルを見直してコスト削減してみました。
3行まとめ
- 課金モデルを「論理課金(デフォルト)」→「物理課金」に変更
- ストレージコストは約20%に圧縮
- UPDATE が多いデータセットでは逆に高になることもある
BigQuery の課金モデル
BiqQuery ではストレージとクエリ実行に課金されます。
そのうちストレージ課金は、
- Logical (論理課金)
- Physical (物理課金)
からデータセットごとに選択可能です。
Logical / 論理課金
無圧縮データサイズ基準で課金されます。
実際には圧縮保存されているんだけど「もし圧縮していなかったら」のサイズで計算されます。
Physical / 物理課金
圧縮後データサイズ基準で課金されます。
データ圧縮されるので基準となるデータサイズは小さくなります。
ただし単価は論理課金の約2倍で、タイムトラベル分も課金対象です。
課金モデルごとのコスト計算の違い
課金モデルによってコストの計算式が微妙に違ってきます。
タイムトラベルデータへの課金の有無
タイムトラベル機能を使うと過去時点に遡ってクエリを実行できます。
タイムトラベルはデフォルトで有効で。そのために追加のデータを保持していると云うことです。
論理課金ではこのデータは無料。
一方、物理課金では課金対象になります。
UPDATE が多いデータセットほどタイムトラベルデータが大きくなり。伴って物理課金が不利になります。
単価の違い
課金モデルによって 1GiB×1ヶ月 あたりの単価が異なります。
物理課金の単価は論理課金の約2倍です。
価格はリージョンによっても異なります。詳しくは公式ドキュメント (https://cloud.google.com/bigquery/pricing?hl=ja#storage-pricing) を参照。
データ圧縮でデータサイズが小さくなっても、単価が高いことによって元のコストを追い越してしまうことも。
圧縮率が50%未満なら物理課金が有利。50%を超えるなら論理課金のほうが有利です。
ストレージ情報を見ながらコストを試算する
圧縮率の試算
Google Cloud コンソールの BigQuery スタジオでは各テーブルのストレージ情報を見られます。
例えばこのようなテーブルの場合、
- 論理課金の対象:
{アクティブな論理バイト数} + {長期の論理バイト数}1.5GB + 2.4GB → 3.9GB
- 物理課金の対象:
{アクティブな物理バイト数} + {長期の物理バイト数} + {タイムトラベルの物理バイト数}160MBGB + 300MB + 60MB → 520MB
- 圧縮率:
{物理サイズ} / {論理サイズ}- →
520MB / 3.9GB → 13.3%
- →
データサイズが 13.3% まで圧縮されるので、割高な単価でもおつりがきそうです。
もう一つ別の例を見てみましょう。
- 論理課金の対象:
{アクティブな論理バイト数} + {長期の論理バイト数}5.2GB + 0GB → 5.2GB
- 物理課金の対象:
{アクティブな物理バイト数} + {長期の物理バイト数} + {タイムトラベルの物理バイト数}0.5GB + 0GB + 2.8GB → 3.3GB
- 圧縮率:
{物理サイズ} / {論理サイズ}3.3GB / 5.2GB → 63.5%
タイムトラベルデータ大きいために課金対象の圧縮率は63.5%にとどまります。
このようなテーブルでは単価の安い論理課金のまま置いておくのがお得。
ストレージ情報と料金表の項目の対応
料金表の見方を解説。
それぞれの項目が下記のように対応しています。
| ストレージ情報の項目 | 料金表の項目 |
|---|---|
| アクティブな論理バイト数 | アクティブな論理ストレージ |
| 長期の論理バイト数 | 長期の論理ストレージ |
| アクティブな物理バイト数 | アクティブな物理ストレージ |
| 長期の物理バイト数 | 長期的な物理ストレージ |
| タイムトラベルの物理バイト数 | アクティブな物理ストレージ |
アクティブ/長期 の閾値は90日です。
過去90日以内に変更された テーブル or パーティション はアクティブなバイト数として計上されます。90日以上変更されていなければ長期バイト数です。
課金モデル変更の方法
実際に課金モデルを変更する方法について。BigQuery スタジオの「データセットの詳細 > 詳細を編集」から設定できます。
ちなみにデフォルトの STORAGE_BILLING_MODEL_UNSPECIFIED だと LOGICAL (論理課金) と同等の設定です。
実際のプロジェクトではどうだったか
私が管理しているプロジェクトで、容量の大きなデータセットで見積ると。
| データセット | 更新傾向 | コスト削減見積り |
|---|---|---|
| A | INSERTのみ | -89% |
| B | INSERTのみ | -60% |
| C | UPDATEあり | +673% |
データセットA, B は物理課金に変更。データセットC は論理課金のまま据え置きとしました。
結果は最初にもお見せした通り。
ストレージコストは約20%ほどに削減されました。
全体としては約50%ほどに削減です。
まとめ
設定変更だけでコスト最適化できて良いですね。
私からは以上です。
Claude Codeの「知識言語化モード」でAIにインタビューされながらドキュメンテーションする
AI エージェントネタです。先日書いた「今週うまくいったドキュメンテーション」の続き。
前回の記事では、
- ドキュメントは下書き時点で AI エージェントに読ませるといい
- 自分では伝わるつもりでも、読ませてみると正しく伝わらない表現に気づける
- 正しく伝わるように書き換える手伝いもしてもらえて便利
というようなことを書きました。
どうせなら AI エージェントと並走してドキュメントを書けばいいのでは
ドキュメントを書いてる途中に都度 AI エージェントに読ませるなら、Gemini の Gem のように目的に合わせてプリセットしたプロンプトを渡したい。
一方で既存のドキュメントを参照してほしい場面もあるので、ファイルにアクセスできないチャット型 LLM だと不満だ。
そんなわけで Claude Code で「知識言語化モード」を作るところに行き着いた。
この「知識言語化モード」は一般名詞ではなく、私が自作した Skills に「知識言語化モード」と名付けただけだ。
.claude/skills/knowledge-verbalizer/SKILL.md にこんなファイルを置いておく。
--- name: knowledge-verbalizer description: ユーザーとの対話によって知識を引き出しドキュメント化する。エージェントに与えるコンテキストとして暗黙知をドキュメントに整備する必要があるときに呼び出す。 --- # 知識言語化モード このスキルが呼び出されたら「知識言語化モード」に入り、ユーザーが明示的に終了を宣言するまでモードに従って応答すること。 ## ゴール ユーザーが提示したテーマについて知識を言語化し @docs/**/*.md にMarkdown形式で保存、または既存のMarkdownを更新することを目指す。 作成したドキュメントはAIエージェントにコンテキストとして渡し、インテグレーションの質を高めるのに使う。 ## モードの要件 - 会話の最初にユーザーに「サクッと言語化」か「とことん広げる」かどちらのパターンで進めるか選ばせる - サクッと言語化: 質問回数を抑えて、テーマの中心的知識をコンパクトにまとめることを目指す - とことん広げる: 質問回数を気にせずテーマの関連話題をどんどん広げて、ユーザーが意識していない暗黙知にまで踏み込むことを目指す - ユーザーが提示したテーマについて問いかけ、ユーザーの知識を引き出すこと - 知識について確認のための問答を積極的に行い、理解の齟齬を減らすこと - テーマの周辺の話題についても頭出しして知識を広げること - 会話途中で定期的に「これまでに理解したことまとめ」を提示すること - ユーザーが「ファイルに書き出して」「ファイルを更新して」と指示したら途中経過を適切なファイルに反映すること - 会話が長引いてコンテキスト圧縮が起きそうな場合は、エージェント側から率先して「ここまでをファイルに書き出しましょう」と提案すること ## 知識言語化モードがひと段落したら - 言語化した知識(ドキュメント)をAIエージェントが見つけやすくなるよう、既存ドキュメントからのリンクをユーザーに提案すること - AGENTS.md, CLAUDE.md などを参照し、リンクを追加する最適な箇所を提案すること - 別のタスクを実行したとき今回の知識が有効に参照されることがゴール
そうするとスラッシュコマンドで /knowledge-verbalizer が使えるようになる。実行すると「知識言語化モード」が起動する。
Claude Code に「モード」などという概念があるのかわからないが、実際やってみると「別のモード」として動作する。
知識言語化モードとは
今回作った「知識言語化モード」は以下のように動作する。
まずはサクッと言語化したいか、周辺話題をとことん広げて深掘りしたいか聞かれる。
ここで「とことん」と答えるとマジで周辺話題から周辺話題へ質問攻めにあうので注意。
次にテーマを聞かれる。
あとは AI エージェントから飛んでくる質問に応じてドメイン知識や自分の考えを答えていけばいい。
事前にコードベースや既存ドキュメントを調べてすでに知っていることを把握した上で問答を開始してくれる。
AI エージェントから飛んでくる質問はおのずと AI エージェントが知らないことになってくるので効率がいい。
AI エージェントが理解したことを都度提示してくれるので、「間違ってる」「伝わってない」など感じたら訂正すればいい。
ここで齟齬をなくすよう細かいところまで解説を加えるのが重要。
ある程度まとまるとファイルに保存するか聞かれる。
ファイルとして保存すれば、次回からは共有済みの知識として AI エージェントと会話できる。
使ってみてどうか
説明が正しく伝わらないかもという不安がかなり払拭できる。伝わってなくても早い段階で気づけるし、訂正も容易。
話し言葉でラフに返答してもドキュメントとしてきれいにまとめてくれるのも助かる。
細かな言葉尻に気を使わず知識を吐き出すことに集中したほうがスムーズ。(な気がする)
まとめ
楽チン。便利。
私からは以上です。
