どうも、おはようございます。マイクです。
今朝は二〇二六年七月三日、金曜日の朝七時を少し回ったところです。
ここからの時間は「zenncast」、きょうもZennで話題になっているトレンド記事を、ゆるっと、でも中身はぎゅっと詰めてご紹介していきます。
きょう紹介する記事は、ぜんぶで五本です。
AIコーディングからデータベースのチューニング、メールアドレスの正しい用語、そして週末でサービスを作り切った話まで、かなりバラエティ豊かなラインナップになっていますので、どうぞ最後までお付き合いください。
まず一本目。
「CLI 前提のツール」という印象が強かった Claude Code を、著者の方がデスクトップアプリ中心のワークフローに切り替えた理由を語っているオピニオン記事です。
もともと Claude Code って、「ターミナルに慣れた人が、CLIでガンガン回していくツール」というイメージ、けっこう強かったと思うんですけど、最近の Desktop アプリ、とくに Code タブの進化がすごくて、「もうこれひとつで日常の開発ほぼ全部いけるじゃん」という状態になってきた、という話なんですね。
デスクトップ版の Code タブでは、複数のセッションを並走させられるうえに、プルリクエストの管理、プレビュー表示、ターミナルなんかも、一画面の中にギュッとまとめて扱える「統合開発環境」っぽいUIになってきています。
サイドバーにはセッションをピン留めする機能やフィルタリングがあって、「このタスク用の会話はここ」「バグ調査はここ」みたいに整理しながら、同時に進められるようになっている。
さらにおもしろいのが、diff や plan、preview といったペインを起点にして、「この変更のこの行だけ直して」とか、「この要素だけ別案出して」といった、かなり細かい行単位・要素単位の指示が自然にできるようになっている点です。
プルリクエスト周りでは、PRバーを使って、CIの状況を眺めながら、失敗したら Claude に自動修正させたり、条件を満たしたら自動マージさせたりといった運用もできるようになってきている。
そして Routine や `spawn_task` を使うと、定型的なタスクをどんどん自動化していけるので、「この種の作業は全部このルーチンで回しておいて」「新しいタスクが発生したら、裏で勝手に回しておいてね」といった、並列タスク前提の運用がすごくやりやすくなっている、と。
著者のまとめとしては、「CLIでも近いことは頑張ればできるけど、ターミナルの多重化やコマンド運用の工夫が必要で、手数も多いし学習コストも高い。とくに非エンジニアや、ターミナルにあまり慣れていない人ほど、まずは Desktop から入るのがいいんじゃないか」という提案になっています。
ターミナル大好き勢も、いちどデスクトップ版の Code タブを本気で使ってみると、「あ、こっちの方がClaudeに任せやすいな」と感じるポイント、けっこうあるかもしれませんね。
。。.。。.。.
つづいて二本目。
こちらは、Claude Code に既存の設計資料やコードのドキュメントをそのまま渡しても、うまく使いこなせない理由と、その解決策として「オントロジー」と「GraphRAG」という考え方を紹介している記事です。
ふつう、システム設計書やリポジトリ構成の資料って、「情報そのもの」はちゃんと揃っていることが多いんですよね。
ところが、Claudeから見たときに、「どの概念がどれを呼び出してるのか」「どのクラスがどのモジュールに依存しているのか」「これはあれの一部なのか、別物なのか」といった関係性は、書類の中では明示されていないことが多い。
そうすると毎回、Claude がその関係を推測しながら答えないといけなくて、精度や安定性にブレが出やすくなる、という指摘です。
そこで出てくるのが「オントロジー」。
これは、概念同士の関係をはっきり書き下したグラフ構造のことを指していて、「このモジュールはこのサービスを呼び出す」「このテーブルはこの集計の一部である」「このAPIはこのユースケースに属している」といった、呼び出す・依存する・一部である、みたいな関係をちゃんと明文化しておくイメージです。
この関係グラフがあると、Claude が「毎回当てずっぽうに推測する」のではなく、「すでに決まっている関係を辿る」ように reasoning してくれるので、幻覚が減り、多ホップな推論もしっかり追えるようになる。
ここで、よく話題になる RAG、いわゆる「検索拡張生成」との役割分担も説明されています。
RAGは、「質問に意味的に近い文書断片を検索してくる」のが得意。一方、オントロジーは、「関係を辿って解くタイプの質問」や、「複数ファイルやモジュールにまたがる整理」に向いている。
両方を組み合わせた「GraphRAG」にすることで、「まずグラフで関連するノードやファイルを絞り込み、そのうえで、その周辺の文書を RAG で持ってくる」といったことができるようになるわけですね。
Claude Code では、MCP の memory サーバなどを使って、コードベースから依存グラフを自動で作り、それを参照しながら回答させる、という実験が紹介されています。
このやり方だと、「関連しそうなファイルをとりあえず全部読ませる」という brute force なアプローチをしなくてよくなるので、トークン消費も応答時間も大きく削減されたそうです。
記事では、コストがだいたい半分になって、レスポンスの速度はおよそ三倍くらい速くなった、という具体的な数字も出ています。
「とりあえずpdfとコード全部食わせとけばいいでしょ」から一歩進んで、「概念と関係をちゃんとモデリングしたうえでAIに仕事をさせる」方向に、そろそろ現場のノウハウがシフトしていきそうな雰囲気を感じますね。
。。.。。.。.
三本目。
これは、実際に起きた「ダッシュボードの集計が遅い」というトラブルを題材に、「どこが遅いのか」を一歩ずつ切り分けて、最終的に十数倍の高速化につなげた、というお話です。
まず最初は、「SQLそのものが遅いんじゃないか？」と疑って調査を始めるんですけど、よくよく見ていくと、アプリケーション側の実装がだいぶボトルネックになっていたことが分かります。
具体的には、データベースから全行を取得しておいて、アプリ側で数え直しているような実装があったり、本来なら独立して実行できる集計クエリを、直列に `await` して一個ずつ処理していたり。
これらを、「DB側でちゃんと集計させる」に変えて、さらにクエリを並列で実行するようにしただけで、かなりの改善が得られたそうです。
次のステップでは、「SQL自体の中でどこが重いのか？」を調べるために、PostgreSQL の `EXPLAIN ANALYZE` を使って、クエリプランをじっくり確認していきます。
すると、`DISTINCT ON` を含むサブクエリの行数を、PostgreSQL のプランナが「二百行くらいだろう」とかなり楽観的に見積もってしまっていることが判明します。
これは `DEFAULT_NUM_DISTINCT` というデフォルト値に引っ張られている挙動で、本当は大量行が返ってくるのに、少ない前提でプランを組んでしまう。
その結果、本来なら hash join や merge join といった、「まとめてガッと突き合わせる」のに向いた方式を選んでほしいところで、nested loop join という、大量行には不利な方式が選ばれてしまっていたわけですね。
ここをどう直したかというと、結合先から「就業形態」を判定するために列を引いていた部分を、`EXISTS` を使った存在チェックに書き換えています。
これによって、「誤って二百行と見積もられてしまったサブクエリ」を結合の起点から外してやることができて、プランナに「hash join や merge join を選べる」余地を与えられるようになった。
つまり、クエリの意味はそんなに変えずに、「プランナが賢い選択をしやすい書き方」に変えてあげることで、性能を引き出した、という形です。
アプリ側の見直しと、このSQLの書き換えを合わせた結果、全体の処理時間はおよそ十七倍も短くなったそうです。
とはいえ、記事ではきちんと「限界」も認めていて、巨大テナントになると、依然として「毎リクエストごとに、母集団のデータを一から組み立て直している」コストが支配的になってしまう、と。
ここまで来ると、もうクエリチューニングの問題ではなくて、キャッシュを効かせるとか、集計テーブルを事前に作っておくとか、そもそもの設計レイヤーで解決すべき話になってくるんだ、というまとめになっています。
「とりあえず `EXPLAIN` 眺めて終わり」じゃなくて、アプリ・SQL・設計、どのレイヤーでボトルネックを切り分けるか、という思考プロセスごと見せてくれている、読み応えのある記事ですね。
。。.。。.。.
四本目。
これは、メールアドレスの「プラス付きアドレス」について、正しい言葉の使い方を整理してくれている記事です。
`hoge+fuga@example.com` みたいな書き方、よく「エイリアス」と呼ばれがちなんですけど、メールサーバ的には、これは別の仕組みで、本来は「subaddressing」あるいは「拡張アドレス」として扱われるものなんだ、という話になっています。
メールの仕様を定めている RFC 五三二一と五三二二では、まず、`@` より右側のドメイン部分が、「どのメールサーバに配送するか」を決める、というルールになっています。
一方で、左側の local-part、つまり `hoge` のような部分については、「どう解釈するか」はサーバ実装に丸投げされている。
`+` 記号自体も、RFC上は特別扱いされているわけではなくて、Postfix や Sendmail など、一部のサーバが「ここから後ろを拡張部分、サブアドレスとして扱おう」という慣習で実装しているにすぎないんですね。
これに対して、本来の「エイリアス」というのは何かというと、たとえば `/etc/aliases` に `hoge: taro, jiro` と書くような、「あるアドレスを、別の一つまたは複数のアドレスに対応づける仕組み」のことを指します。
つまり、「hoge に届いたメールは、たろうとじろうに転送してね」といった設定ですね。
`foo+bar@example.com` が、何の事前登録もなしに自動的に `foo@example.com` に集約される subaddressing とは、仕組みとしてはまったく別物です。
現場では、サービス側が `+` を含むアドレスを禁止していたり、Gmailがマーケティング的な理由で「これはエイリアスですよ」と説明していたりと、いろいろ事情が混ざっているので、「プラス付き＝エイリアス」という理解が広まってしまったところもあります。
ただ、技術的に正しく整理するなら、「プラス付きアドレスは、ローカルパートの一部を区切って使うサブアドレス」「エイリアスは、あるアドレスを別のアドレスに紐づける機構」として、きちんと区別したほうがいい。
筆者のメッセージとしては、「今後は用語を意識して使い分けてほしいし、『プラス付き＝エイリアス』と教え広めるのはちょっと不正確なので、そこは直していきませんか」という呼びかけになっています。
普段なんとなく使っている用語でも、RFCレベルで見ると「え、そうだったの？」となる、いい例ですね。
。。.。。.。.
そして五本目。
最後は、エンジニアの方が週末二日間で、「AIにほぼ全コードを書かせて、家計簿SaaSをMVPからデプロイまで作り切った」という体験をもとに、これからの開発スタイルを考察している記事です。
この方は、Claude Code をフル活用していて、まず Plan モードで設計やタスク分解をAIにやらせます。
「どんな機能が必要か」「どの順番で作るか」といったところを、Plan で整理してもらったうえで、今度は auto モードに切り替えて、Issueごとにプルリクエストを自動生成させていく。
人間である本人は、実装そのものというより、「レビューと全体方針の決定」に専念する、という進め方をしています。
ここでキーになっているのが、「ハーネス」、つまり開発を支える枠組みをきちんと用意することだ、と記事では強調されています。
テストやデプロイの自動化、E2Eテスト、ステージング環境などをしっかり整えておくことで、「AIが大量にコミットしてくるコードを、安全に・高速に回していける」状態を作る。
ハーネスが貧弱だと、どれだけAIが頑張っても、人間側の確認や修正に時間を取られてしまうので、スピードが出ないんですね。
コードの質そのものについては、「かなり高いレベルにある」と評価していますが、それでもタスク漏れや確認不足はどうしても起きるので、人間の役割はだんだん「実装者」ではなく、「計画を立てる人・進捗を管理する人」「レビューと品質保証をする人」「AIエージェントの監督者」にシフトしていくだろう、と考察しています。
さらに、新規開発のスタイルも変わっていきそうで、「まずいっぱい資料を書いてから作る」という従来のやり方よりも、「とりあえずMVPをサクッと作って、ユーザーに触ってもらいながら要件を詰める」スタイルが、現実的かつ主流になっていくんじゃないか、とまとめています。
週末二日でここまで行けるなら、「とりあえず作ってみる」のハードル、かなり下がったなあ、という感覚になりますね。
。。.。。.。.
というわけで、きょうの zenncast、お届けしてきました。
駆け足でおさらいすると──
一つ目は、CLI 前提というイメージだった Claude Code を、デスクトップアプリの Code タブ中心で使うメリットと、「並列タスク前提でAIに仕事を任せる」運用の話。
二つ目は、オントロジーとGraphRAGを使って、コードベースの関係性を明示し、幻覚を減らしつつコスト半減・約三倍速の回答を実現した事例。
三つ目は、ダッシュボード集計遅延を、アプリ・SQL・設計のレイヤーで順番に切り分けて、最終的に処理時間をおよそ十七倍短縮した話。
四つ目は、`hoge+fuga@example.com` のようなプラス付きアドレスは、本当は「subaddressing（拡張アドレス）」であって、エイリアスとは別物ですよ、というメールアドレス用語の整理。
そして五つ目は、週末二日で、AIにほぼ全コードを書かせて家計簿SaaSをMVPからデプロイまで作り切り、「人間の役割が監督・計画・レビューにシフトしていく未来」を考察した記事でした。
きょう紹介した記事の詳しい内容や、気になったキーワードは、ショーノートにまとめてありますので、もっと深掘りしたい方は、あとでゆっくりチェックしてみてください。
この番組「zenncast」では、みなさんからの感想や質問もお待ちしています。
「こんなテーマを取り上げてほしい」「この記事が面白かった」などなど、気軽に送ってもらえると、マイクが次回のネタ選びでめちゃくちゃ参考にします。
それでは、そろそろお別れの時間です。
きょうも良い一日をお過ごしください。お相手はマイクでした。
また次回の zenncast でお会いしましょう。