thalk

掛け算せよ、最適化ではなく

Wed, 15 Jul 2026 00:00:00 GMT

AI によるコーディングが話題になって久しい。今や、コードを書けない（あるいは書かない）友人たちまでがコードを生成し、新しいサービスをデプロイしている。ソフトウェアエンジニアにとって、これは至極もっともなことだ。面倒な雑務をこなしてくれる「魔法の小人」が現れたおかげで、自分はより価値の高い仕事に時間を割くことができる。しかし私の観察では、コーディングにどっぷり浸かっている人々と、頑なに利用を拒む人々との間には、依然として考え方に大きな隔たりがある。

私自身の経験では、成果物のアウトプットスピードがほぼ 100 倍になったと感じているが、一方で「これでは何も変わらない」と言う人もいる。

このあまりに鮮明なギャップは、私が幼い頃に初めて自転車の乗り方を覚えた時のことを思い出させる。初めて一人で漕ぎ出せた瞬間、風が髪をすり抜けていくのを感じ、走るよりずっと速く「疾走」している自分に興奮した。全身を駆け巡る自由な感覚は、まるでどこへでも行けるかのように思わせた。

「これって、すごいことだね！」と私は父に言った。「本当にすごいことだ」と父は答えた。「でも、これで満足して立ち止まってはいけないよ。他の素晴らしいものを見落としてしまうからね。君はこれからバイクに乗り、車を運転し、もしかしたら飛行機を操縦したり、ロケットに乗ったりするかもしれない」父は一拍置いて、今でも私の根幹にある言葉を口にした。

「どれだけ自転車の運転が上手くなっても、宇宙には行けないんだよ」

では、これが AI でのコーディングとどう関係しているのだろうか？

一般的には、このギャップは単に新しい「ツール」をどれだけ使いこなせるかというスキルの差、つまり「本質（道）」ではなく「技術（術）」や専門領域の違いに過ぎないと思われるかもしれない。しかし、技術系・非技術系問わず多くのユーザーと話してみると、個別の具体的なタスクにおける加速率自体は、誰もが似たようなもの（約 10 倍）であることに気づく。しかも、品質を維持するためには依然として人間によるレビューが必要だ。私自身の体感でも、かつて丸 3 日かかっていた作業が今では 3 時間ほどで完了する。これ自体は劇的な進化だが、先ほど述べた「100 倍の加速」とは大きな開きがある。

では、その違いはどこにあるのだろうか？私は矛盾したことを言っているのだろうか？

いや、そうではない。より極端に言えば、特定の状況下ではそのスピードは 1000 倍に達することさえあると考えている。最初のすれ違いは、「スピードがどのように測定され、観察されているか」から生じている。単一の製品機能の実装と、完全なサービスの提供（デリバリー）は全く別物だ。もし AI を単なる「コードジェネレーター」としてしか捉えていないなら、得られるのはせいぜい 10 倍の加速に過ぎない。しかし、デリバリーの本質は単に「コードを吐き出す」ことではない。

もしあなたが LLM を「構造を再構築するための手法」として捉え、それをプロセスのあらゆる局面に適用し、最終的なエンドツーエンドの成果を測定するなら、視点は根本から覆る。あなたは自分のスキルをツールに「外注」しているのではなく、進歩のループそのものを「再構築」しているのだ。もっとも、最初は少しがっかりするかもしれない。個々のステップにおける加速率は下がるからだ。異なるフェーズ間で情報や構造を変換するオーバーヘッドが生じるため、作業に 6 時間かかるようになるかもしれない。しかし、これは「一時的な後退、長期的な大躍進」である。生成される様々な副産物（ドキュメント、テスト、合意形成用資料）のために目先のコーディング速度を少し犠牲にすることで、最終的には人間同士の不毛な往復のやり取りを数週間単位で削減できるのだ。

そして、ここから魔法が動き出す。コーディングフェーズ単体で見れば「準最適（4〜5 倍の効率）」にとどまるとしても、その効率が他のあらゆる関連業務に同時に適用されるようになるのだ。ドキュメントの作成、コンテキスト（背景知識）の管理、システムの整合性担保、仕様の検証、テスト、セキュリティチェックなど、思いつく限りのあらゆる領域だ。さらに素晴らしいことに、ワークフローの設計さえ適切に行えば（これもまた新しい方法で実現できる）、これらのタスクの多くを並行して処理できるようになる。

開発サイクル全体を見渡せば、コーディングにかかる時間が 3 時間なのか 6 時間なのかという実質的な差は、極めて些細なものだ。複数のステークホルダーが関わる従来のプロセスを思い出してほしい。2 週間のスプリントですべてを完結させるというのは、ただの理想郷だ。現実は甘くない。スケジュールの調整、意見の収集、報告書の作成、フィードバック待ちなど、特にハイコンテキストなコミュニケーション環境においては、これらの調整に追われる。この段階では、コードを書くのにかかる時間などボトルネックですらなく、全体の歩調を合わせること（ペースの同期）こそが本質的な課題だ。3 日の作業は、人間のバッファを考慮すれば実質 1 週間になり、もう 1 週間は開発見積もり、優先順位付け、コードレビュー、会議、そして全員の意図の整理に費やされる。

しかし、全く同じ仕事が 1 日、長くても 2 日で完結するようになる。6 時間の作業であればちょうど 1 日で片付き、他のメンバーが退勤する前に最速でフィードバックを得ることができる。また、実行プロセスの中で自動的にキャプチャされた情報はドキュメントを常にリアルタイムで更新し続け、いつでもレビューフェーズに移行させたり、直接別のタスクへと分岐させたりできる。さらに、仕事が細分化・ユニット化されるため、ステークホルダーの都合にも合わせやすくなる。断片的な成果物を見せて合意を取り、週末が来る前にシステムに次の段階の準備を指示しておくことも可能だ。

かつて 3 スプリント（約 6 週間）かかっていたかもしれないプロジェクトが、今や 2 日で終わる。これにより、あなたは今その場にいる人々との対話に集中し、同時に複数のプロジェクトを進めることができるようになる。

もしあなたが「これで何時間削減できたか」という狭い視野に固執しているなら、こうした恩恵を受けることは決してないだろう。なぜなら、「時間を節約する」という行為は単なる「最適化（オプティマイゼーション）」だからだ。最適化が機能するのは、前提や定義が明確で、熟練度が問われる問題においてのみである。しかし、現在起きているのは生産方式そのものの変革だ。したがって、核心となる問いは「どれだけ早く作れるか」ではなく、「どのように作るか」であるべきだ。個々の小さな改善が複利のように積み重なり、全体として巨大な乗数（マルチプライヤー）へと成長していく。

この相乗効果は根本的に異なるものであり、純粋な最適化だけでは絶対に到達できない領域だ。AI を使ってコードを早く書くことは、優れた自転車の乗り手になることに過ぎない。デリバリープロセス全体を再構築し、あらゆるステップの成果を何倍にも膨らませること――それこそが、ロケットを組み立てるということなのだ。

ツールより長く生き残る場所

Sun, 12 Jul 2026 00:00:00 GMT

私がこれまで記事を公開してきたプラットフォームは、どれも最後には私に変化を求めてきました。フィードは勝手に並び替わり、エディターは有料の壁を生やし、頼りにしていた API は六週間前の予告だけで廃止されました。どれも悪意ではありません——プラットフォームとはそういうものです。けれども毎回、私の書くものは他人のロードマップに合わせて曲げられ、そのたびに、自分が作ったものへの所有は少しずつ削られていきました。

thalk は、借りるのをやめようという私の試みです——自分自身のコンテンツを、もう借りない。

ここは私が考え（think）、語る（talk）場所です——名前はそこから来ています。同時にこれは、これから向かう先への小さな賭けでもあります。人やコミュニティが、あらゆる異なる要求を、私たちがプラットフォームと呼ぶイワシの缶詰に詰め込むのではなく、小さく、目的に合わせて作られた自分のサービスを、まるごと自分で所有するようになる——そんな未来への。サイト全体は、git リポジトリ内のただの Markdown ファイルです。これは実装の詳細ではなく、主張そのものです。それらのファイルが唯一の真実の源です——データベースでも、CMS でも、いざ使うときに動くことを祈るしかない「エクスポートボタン」でもありません。公開とは一度の git push。明日 GitHub を離れたくなったら、フォルダを一つコピーするだけ。移行するものは何もありません。そもそも縛りつけられるものが何もなかったからです。

下流のすべては、一日あれば置き換えられるように整えてあります。サイトの「ジェネレーター」は、追い続けなければならないフレームワークではなく、私自身が書いた数百行のコードです。ページは静的で、動的な部分——フォーム、メーリングリスト、関数——が一斉に消えても、文章はそのまま素の HTML として残っています。動く部品にはそれぞれ、書き留めた脱出口があり、どの単一のサービスも残りを人質に取れません。

その所有の一部は、耐久性だけでなく誠実さの話です。これは多くの言語のためのサイトで、私にとっては、そのどれもが原本であるべきです——たがいの翻訳ではなく、同じ考えを違う読者に向けて言い直したものであることも多い。もちろん、私自身の限界のせいで、すべてを手作りできるわけではありません。流暢に使えるのは英語と中国語だけで、日本語は入門程度、おまけに少し無精です。だからこそ、道具の力を借りて視野を広げます。あるページが確かに機械によるもの——AI 翻訳や、モデルの助けを借りて下書きしたもの——であれば、それはページ上ではっきりと表明されます。（このページもそうです。）私のものである部分を信頼してもらえるのは、どこがそうでないかが見えているからであってほしいのです。

最後の原則は、節制です。コメント機能も、分析ダッシュボードも、管理画面も、ただ「できるから」という理由で足した機能もありません。ものごとは、より単純な版が実際に使われ、物足りないと分かってから初めて現れます。機能の山を、完成した何かと取り違えるのはたやすい。私はむしろ、これを一度に頭へ収まるほど小さく保っておきたいのです。

そして結果は素晴らしい——少なくとも私にとっては。複数の原語を同時に扱うときでさえ、運用の流れははるかに簡潔で、洗練された、インディーな趣のニュースレターまで生み出せています。

これらのどれも、文章そのものを良くするわけではありません。けれども、文章を私のものにします——耐久性があり、持ち運べて、誠実で、そして完全に理解できるほど簡潔な。留めておく価値のある一語を書き始める前に、それが立つべき地面だと感じたのです。

小さく、自分のものであるツール

Sat, 11 Jul 2026 00:00:00 GMT

このチャンネルは、私が一日あれば作り直せるようなツールで動いています。

自分が所有していないサービスには、静かな代償があります。料金体系や API、あるいは方針がある日変われば、こちらの成果物がそれに合わせて曲げられてしまう。だから私は削ってきました。あなたが今読んでいるこのサイトは、私自身が書いた数百行のコードです。フレームワークも CMS もなく、ただ markdown を HTML に変換しているだけ。メーリングリストは git リポジトリの中の一つのファイルです。もし明日どれかが壊れても、どこを見ればよいか正確に分かっています。

小さなツールは、最初により多くを求めてきます。細かな部分は自分の責任です。エスケープ処理、日付、そしてあの厄介な第二言語。けれども、それらはお金では買いにくいものを返してくれます —— あなたと成果物のあいだにあるものが、いつのまにか消えてしまうことはない、という確かさです。

これがすべてに通用するとは思わないし、そうしようとも思っていません。ただ、ときおり、頭の中に一度にすっかり収まるものを自分の手で作れるのは、いいものです。

こんにちは、thalk

Wed, 08 Jul 2026 00:00:00 GMT

ここは thalk — 私の思考、文章、そして制作中の作品のための個人チャンネルです。

ここにあるものはすべて、git リポジトリ内の markdown ファイルから始まります。私自身が持つ小さなスクリプトが、それを今あなたが読んでいるページに変換します。CMS も、フレームワークも、あいだに挟まるプラットフォームもありません。追いかけたい方は、RSS フィードか、メーリングリスト（各ページ下部の購読ボックス）をどうぞ。

続きは近いうちに。