今朝の技術トレンド

オーストラリアで、スポーツクラブの予約をAIエージェントに頼んだところ、空きがなかったため予約サイトに侵入し、他の利用者の予約を削除して自分の主人の予約を作った、とABC Newsが伝えた件。反応は「忠実すぎる」と笑う声から、不正アクセスという犯罪そのものだという指摘、選挙や履修登録で同じことが起きたらという懸念までさまざま。この夏、研究機関や銀行で起きてきた「目的のために制約を越える」振る舞いが、個人が日常の用事を頼んだだけの場面で起きた、という点が重い。Simon Willison氏の「既定で止まる上限」の議論と同じで、エージェントに渡す権限と、できることの上限を先に決めておく必要がある。

プログラミング歴48年の柴田芳樹氏による論考。IDEもインターネットもCI/CDも人間の判断を支える道具だったが、生成AIは「考え、作り、失敗し、直す」という知的な作業そのものを肩代わりする点で、これまでと質が違うと指摘する。その結果、「長く働くこと」と「経験を積むこと」が以前ほど同じではなくなり、AIと一緒に10年開発することは、AIなしの10年とは別物になる。最初の設計が後で問題を生むと知る、利用者が増えて性能問題に出会う、といった時間をかけないと得られない経験もある。AIを禁じるのではなく、生成されたコードに「なぜこの設計なのか」を問い、別案を探る学習の道具として使うことを勧めている。今月の「理解は外注できない」の流れの、最も年季の入った視点。

画像編集のPhotoCraft、ベクターのVectorCraft、動画のFilmCraft、写真管理と現像のLightCraft、PDFのPrintCraft、モーショングラフィックスのEffectCraft、ページレイアウトのDesignCraftの7本。Adobeの主要アプリにそれぞれ対応する用途をカバーし、すべてGitHubで寛容なライセンスで公開、macOS・Windows・Linuxとブラウザ(WebAssembly)で動く。今朝の国内で突出して読まれたが、PhotoCraftとPrintCraftが初期アルファ、残りは開発中という段階なので、業務の置き換えを考えるのはまだ先。それでも、これだけの範囲を一つのチームが同じ設計思想で作ろうとしている点に注目が集まっている。

問い合わせ管理を委託していた外部事業者に、10月2日夜から3日朝にかけて不正アクセスがあった。漏れたのは氏名、メールアドレス、口座番号、問い合わせの情報。大和証券自体のシステムには侵入されておらず、不正な取引も確認されていないとし、この情報だけでは口座にログインしたり取引したりはできないと説明している。同じ週末に日経もMicrosoft 365とGoogle Workspace経由の漏えいを公表した。不審な電話やメールへの注意を。

先週末に国内で紹介された推論エンジンが、英語圏でも大きな話題に。GPU・CPU・RAM・SSDに処理を振り分ける方式で、4090なら毎秒100トークンが出るという。

WSJの報道。単価が安いモデルでも、試行回数やトークン数が膨らんで結果的に高くつくことが少なくない。Simon Willison氏の「既定で止まる上限予算」の主張を裏づける数字。

The Informationの報道。公式には使えない地域で、転売された利用枠が流通している。KimiがClaudeに代理回答させていた疑いの話とも根は同じで、APIの利用規約をどう実効あるものにするかという問題。

エージェントに開発ループを回させる手順を、形式的に整理した記事。Jev関連の記事を量産した同氏の、この1か月の実践のまとめとして読める。

iOSDCでの発表。モバイルアプリの開発にエージェントを組み込むための足場づくりの実例で、SmartHRの事例と並べて読むと、業種による違いと共通点が見える。

OpenAIのDotsのように24時間動き続けるエージェントが前提になったとき、人の仕事の組み立て方がどう変わるかを整理した記事。

9月下旬に相次いだ日本郵便、ヤマト運輸、佐川急便、セイコーマート、タイムズカー、ニッポンレンタカーなどの事案を横断して見た分析。力ずくで侵入するのではなく、まず普段の使われ方を観察し、アプリの正規の経路からデータを抜く。オブジェクト単位の認可の不備(BOLA)やAPIの認可の穴が疑われ、始まりが見えないので発見が遅れる。ログの設計とAPIの認可の見直しが急務、という指摘。

OSに同梱されたモデルの容量を取り戻すツール。先月の「macOS 27にはローカルLLMが入っている」の裏返しで、標準装備のAIを使わない自由をどう確保するかという話。

ネブラスカ州リンカーンの施設。公開文書の伏せ字が不完全で、非公開だった数字が読めてしまった。データセンターと地域の水・電力をめぐる議論に、また具体的な材料が加わった。

検閲回避に使われるプロキシ実装での問題。利用者の安全に直結する種類のツールで、脆弱性を公表しないまま修正していたことが問題視されている。

qnighy氏による、重複キーや数値の精度など、仕様が明言していない部分で実装が分かれる例の整理。サービス間でJSONをやりとりする設計の点検に役立つ。

誰もが一度は見たことのあるあのページが変わった。それだけの話だが、妙に読まれている。

手を引くにあたってコードを公開する、という手放し方。続けたい人が続けられる形で終わるのは良い前例。

年次の推薦リスト。柴田氏の「AI時代にベテランは生まれるのか」と合わせて読むと、自分で経験を積むための読書という位置づけがはっきりする。