C2PA(デジタル署名付きメタデータ)は、画像に改ざん不可能な作成者情報を付与する仕組みで、EUのAI規制法でも言及されている。しかし現状、AI生成画像にしか普及しておらず、人間が撮影した写真の大半は署名されていない。これを機能させるには、あらゆるカメラやスマホでのデフォルト署名、SNS事業者によるメタデータ保持など、大規模な技術・規制対応が必要であり、実際に有用になるまでには長い年月がかかる。
seangoedecke-com
seangoedecke-com から 30 件
ブログ記事を書く最良の方法は、自分がまだ完全には理解していないトピックについて、明確で議論を呼ぶ主張をすることだ。筆者は哲学と詩作の経験から、制約のある構造の中で書く方が「自由な自己表現」よりもはるかに生産的だと述べる。執筆中に意見が変わったり、結論が導入部よりはるかに良くなるなら、それは学習が起きている証拠であり、初心者だからこそ書ける入門記事には価値がある。また、LLMからのフィードバックも有効な学習手段として推奨されている。
EUのAI法ではAI出力に透かしを入れることが義務付けられるが、テキストの透かしは原理的に簡単に除去できる。LLMのトークン生成に影響を与えるSynthID方式や、Unicodeの同形文字(ホモグリフ)を使った方式があるが、言い換えやUnicode正規化で容易に除去可能。技術的ユーザーはもちろん、非技術者でも簡単に使える除去ツールが登場するだろう。
当たり前のことを言う
1.5当たり前のことを述べるのは驚くほど有用だ。多くの知見は意識下に潜んでいるため、既に知っていることを文章で再認識できる。特に「誰も口にしないけれど明らかな真実」を言語化することで、読者に「自分は狂っていなかった」というカタルシスをもたらすことができる。当たり前のことを書くのは難しいが、それを避けずに書き留めることで、より高度で繊細な議論へと進む基盤ができる。
AI推論は明らかに儲かる
4.0AI推論は採算が取れず、投資家の投機マネーで成り立っているという主張があるが、実際の計算やオープンなLLMの事例はこれに反する。NVIDIA A100を用いた70Bモデルの推論コストは出力トークン100万あたり約1ドルで、OpenAIやAnthropicの価格設定($4.50〜)は70〜80%の粗利率と整合する。DeepSeekの事例も同様の利益率を示しており、AIラボが高いマージンを取る理由は推論利益で新モデルの訓練コストを賄うためだが、純粋な推論プロバイダーは訓練不要で利益を出し続けられる。AIバブルが弾けても推論ビジネスは終わらない。
LLMをプログラムに組み込む方法は、パイプライン(コードで制御フローを定義)とエージェント(LLM自身にツールを与えて制御させる)の2つに大別される。パイプラインは予測可能性とコスト管理に優れるが、エージェントはより難しいタスクに対応でき、特にコンテキスト収集が容易で未来志向だ。本記事では両者のトレードオフを解説し、迷ったらエージェントを選ぶべきだと提言する。
「LLMがコードを書くのが得意なら、AIが生成したアプリやサービスの津波がどこにあるのか」という疑問に対し、筆者は過去12ヶ月にAIの助けを借りて実際に出荷した個人的なプロジェクト群を紹介。SkiFreeのWordle風デイリーゲーム「Skifreedle」、自動生成の暗記カードアプリ「Autodeck」、リンククリックでページを探索する「Endless Wiki」、植物識別データベースのオフラインPWAなど、AIなしでは実現しなかった多様なプロジェクトを挙げ、小規模で奇妙なプロジェクトの洪水が起きていると主張する。
本稿は、AIやLLMに否定的な言説に見られる「偉大な過去への回帰」というレトリックが、ファシズムの思考構造(伝統崇拝、近代化 rejection、精神的エリート主義)と驚くほど似ていることを指摘する。ラッダイト運動や『指輪物語』へのファシストの共感を例に挙げつつ、筆者は「反AIが即ファシズムだ」と主張するのではなく、むしろ両者の修辞的・感情的類似性に注意を促す。技術の善悪を単純化せず、AIが障害者支援などに実際に役立つ事例も紹介しながら、ソフトウェアエンジニアというエリート集団が「過去の理想」にすがる危険性を警告する。
ソフトウェアエンジニアは、日々の業務を80%の稼働率で進めることで、突発的な高インパクト案件に対応できる余裕を生み出すべきだ。技術企業でのパフォーマンスは「外れ値となる出来事」に支配されており、常に全力でタスクをこなしていると、大きな成果につながる機会に気づけなかったり、マネージャーからアサインしてもらえなくなったりする。あえて「何もしない」時間を作ることで、ストレスを軽減し、本当に重要な問題に集中できるようになる。
エンジニアとプロダクトマネージャーの関係は、信頼の欠如、操作、嘘によってしばしば機能不全に陥る。PMは技術的判断を検証できず、エンジニアは組織全体の優先度の変化を理解できない。良い関係を築くには、相手の立場を理解し、正確な情報を提供し、政治的な判断を任せることが重要。PMと信頼関係を築ければ、組織内で大きな影響力を発揮できる。
AI推論用GPUの寿命は「せいぜい3年」という主張が根拠薄弱であることを検証。匿名のX投稿を出典とするこの説に対し、Googleが8年前のTPUを現役稼働させている事例や、AWSがA100サーバーを一度も退役させていないというCEO発言、スーパーコンピュータTitanの6年間で90%以上のGPUが生存した統計データを提示。経済的寿命と物理的寿命を区別すれば、AIバブル崩壊後もGPUは長期にわたり採算性を維持できると論じる。
OpenAIのo3モデルが写真から位置を特定するGeoGuessrタスクで驚くべき性能を示したと話題になったが、実際に「魔法のプロンプト」と呼ばれた詳細な指示文が効果を持っていたのか検証した。200枚の画像を使ったベンチマークの結果、シンプルな標準プロンプトと比較して、精巧なプロンプトは平均精度で劣っており、むしろ「プロンプトのおかげで成果が出た」と思い込む危険性を示している。モデルがすでに十分な性能を持っている場合、複雑なプロンプトを与えても効果はなく、改善の錯覚を生むだけだ。
コードだけでなく、AIエージェント向けのプロンプトも技術的負債になり得る。プロンプトの調整は大きな価値を生むが、モデル固有であり、モデルのアップグレードごとに機能しなくなる可能性がある。コードと違い、プロンプトの劣化は静かに進行し、気づきにくい。理想的には、サードパーティ製AIコーディングツールを最小限の設定で使い、プロンプトはプロジェクト固有の具体的な事実に限定し、不要になったら削除すべきだと論じている。
シニアエンジニアの中には、コード追加に「ノー」と言い続ける「just-say-noエンジニア」というアーキタイプが存在する。この役割はZIRP(ゼロ金利政策)時代には重要だったが、金利上昇とともに企業のエンジニアリング文化が変わり、彼らの立場は一変した。この変化はAIのせいにされることが多いが、実際にはZIRP終焉による経済的要因が本質であり、AIは後付けの説明に過ぎない。
スタッフエンジニアが2025年から2026年にかけてのLLM活用の変化を解説。エージェント性能が大幅に向上し、コード変更の大半をエージェントに任せ、バグ調査やテスト・環境設定にも積極的に活用している。一方で、PR説明文やメッセージなどのパブリックコミュニケーションやUIテストにはAIを使わず、適切なバランスを見極めることが重要だと述べている。
本記事では、LLMの推論中に活性化値を直接操作して出力を制御する「ステアリング」技術について解説する。従来は強力なローカルモデルがなかったため実用的ではなかったが、DeepSeek-V4-FlashとDwarfStar 4の登場により状況が変わりつつある。著者は、ステアリングの基本的な仕組みや有望なユースケースを紹介しつつ、プロンプトやファインチューニングに比べた限界にも触れ、今後のオープンソースコミュニティの動向に期待を寄せている。
イーロン・マスクが提唱する宇宙AIデータセンター構想に対し、「宇宙では放熱が困難」という批判がよく上がる。しかし本記事は、放射冷却を活用すれば宇宙でも冷却は可能であり、必要な面積は確かに大きいが実現不可能ではないと指摘。冷却は総打ち上げ質量の比較的小さな要素に過ぎず、本当の課題は別にあると論じている。
Thinking Machinesが発表した「インタラクションモデル」は、フロンティアモデルではなく、完全二重音声(全二重)によるリアルタイム対話を改善する技術である。ChatGPTのような「聞くか話すか」の切り替え方式とは異なり、200ミリ秒単位のマイクロターンで常に聞きながら話すことを可能にし、割り込みや同時発話にも対応。さらに、高速な対話モデルに別の高知能モデルをタスク委任する仕組みやビデオ入力の統合も特徴で、規模を拡大した全二重モデルとして注目される。
AIに対する左派の主張
3.5左派の間で広がるAI反対論は、2022年の暗号通貨バブルや2024年のビッグテックCEOたちのトランプ支持など、AIそのものとは無関係な出来事への反動でもあると筆者は指摘。本稿では、障害者支援、慢性疾患患者の医療情報アクセス、階級を超えた「危険なプロフェッショナル」的コミュニケーションの実現、教育格差の是正、そして左派的ユートピアの実現可能性という5つの観点から、左派ならではのAI推進論を展開する。
ソフトウェアエンジニアリングの能力は大きく偏っており、最弱のエンジニアはしばしばプロジェクトに悪影響を及ぼす。しかし、Claude Codeなどの最先端LLMは、弱いエンジニアのアウトプットの最低水準を引き上げた。彼らが以前のように明らかに動かないコードを提出する代わりに、少なくとも行単位では機能する標準的なLLMのプルリクエストを出すようになった。ただし、この状態はエンジニア個人の学習機会を減らし、企業にとっては給与に見合わない価値しか生み出していない可能性もある。
インシデント対応の大半は「待つ」ことであり、多くの障害は自然に回復する。しかしエンジニアは焦って対処し、かえって事態を悪化させがちだ。有効な対応は「何もしない」ことから始め、システム知識に基づいてシンプルな変更(機能フラグの無効化など)を行うことにある。インシデント解決は政治的な信用を買うが、それだけを頼みにすると持続可能な立場にはならない。
より高難度のタスクをこなすAIモデルの訓練には多くのFLOPs(計算処理)が必要となるため、AIの進歩は鈍化すると考えられた。しかし実際は、①モデルがFLOPsを桁違いに効率的に使えるようになったこと、②人間の知能評価は主観的で当てにならないこと、③「知能」だけでなく記憶力や粘り強さなど多様な特性が能力を左右すること——などの理由から、AIの進歩は鈍化していない。訓練の効率化や「稲妻のような」革新的アイデアが、理論上の制約を上回っているのだ。
Will Larson氏が提唱した「スタッフエンジニア・アーキタイプ」は有用な分類だが、それを目標として追いかけるのは逆効果だと論じる。真にスタッフエンジニアとして成功するには、アーキタイプを目指すのではなく、日々の実直な仕事を通じて信頼を築き、「会社にとって役立つか」を常に問い続ける姿勢が重要である。役割の本質は、自分ではコントロールできない結果に対して責任を負うことであり、その不公正さを受け入れることがスタッフエンジニアの第一歩だと説く。
AIツールの活用は長期的にエンジニアのスキルを低下させる可能性があるが、短期的な生産性向上のために使わざるを得ない状況が訪れるかもしれない。建設作業員が重い物を持ち上げることが仕事であるように、AIの使用がエンジニアの認知能力を犠牲にしても、競争に生き残るためには従う必要がある。著者は、ソフトウェアエンジニアがプロアスリートのように15年程度のキャリアスパンになる可能性を指摘し、その備えの重要性を説いている。
ラッダイト運動に関する2冊の書籍『The Luddites』と『Breaking things at Work』『Blood in the Machine』の読書ノート。ラッダイト運動は織物工という特定職種による極めてローカルな抵抗運動であり、具体的な要求を持ち、ほぼ完全な階級的連帯を見せたが、最終的には国家によって徹底的に鎮圧された。著者は現代のAI・自動化への抗議運動とラッダイト運動の類似点と相違点を分析し、ラッダイト運動が「労働者階級」を形成したことや、後年の労働改革の基盤となったことを指摘する一方、抗議運動として最終的には敗北したと結論づけている。
AIに反対する人々が「新しいラッダイト」を自称し、データセンターへの破壊行為が現実化するなか、19世紀イギリスのラッダイト運動の実像を歴史的資料から検証する。ラッダイトは機械の破壊や時には殺人に及ぶ暴力運動だったが、極めてローカルで分散的な組織形態を持ち、地域社会の圧倒的支持に支えられていた。しかし現代のAI反対運動は、影響が地理的に限定されず、標的も遠方にあるため、ラッダイト戦略をそのまま適用することは難しいと論じる。
著者は、現在機能しているAIプロダクトはチャットボット、コーディング補完(Copilotなど)、エージェント(Claude Codeなど)の3種類のみだと主張する。AI生成フィードやAIベースのゲームは将来性があるが、まだ成功していない。多くの「新AIプロダクト」は単なるチャットボットであり、ChatGPTとの競争に直面している。
新しいAIモデルの実力を評価するのは困難だ。公式評価(evals)はマーケティングツールとなりがちで、直感的な「バイブチェック」も信頼性に欠ける。実際の業務でモデルを試すには時間と労力がかかり、モデルが人間より賢くなると、その進歩を認識すること自体が難しくなる。これがAI進歩が停滞しているように見える一因かもしれない。
この記事では、目標に向かって常に前進できる「ブロックされない状態」になるための具体的な方法を提案しています。複数のタスクを並行して進める、作業の順序を適切に計画する、開発環境を安定させる、他のサービスの問題も自ら調査する、他チームとの関係構築に努める、上級管理者の支援を活用するといった戦略を紹介しています。
大企業では、エンジニアの平均在籍期間が短く、頻繁な異動により多くのエンジニアが不慣れなコードベースで作業しているため、質の低いコードが生まれやすい。経験豊富なエンジニアも過負荷で全てをレビューできず、企業は専門性よりも柔軟な人員配置を優先するという意図的なトレードオフを取っている。