2026/07/10 20:36

蓄積型エディティング

RSS: https://news.ycombinator.com/rss

要約▶

日本語翻訳:

大規模言語モデル（LLM）は頻繁に「蓄積的編集（accretive editing）」と呼ばれる失敗に見舞われます。これは、古いテキストに新しい修正を追加するのではなく、陳腐化した情報を置き換えるために失敗することを指します。Amazon Bedrock と LiteLLM を含むアップデートで観察された事例では、プロジェクトがもはや Amazon Bedrock をサポートしていないという指示にもかかわらず、モデルが Amazon Bedrock への言及を削除できませんでした。これは、LLM が入力を代替するのではなく結合すべき有効なコンテキストとして扱っているためです。「簡潔な記述」を要求するなどの標準的な解決策は陳腐化された事実を短い文に置き換えるだけではあり、これらを削除していないため失敗します。過去の過ちを積極的に消去する人間とは異なり、現在の AI アーキテクチャは履歴を含むすべての入手可能な入力のみに基づいて次の単語を予測します。「何をすべきでない」こと（例：「蓄積的編集を避ける」）と指示するだけでは、「何をすべきか」に具体的に指示することほど効果的ではありません。推奨される解決策は、プロンプトを 3 つのパートに再構成することです：古い陳腐化した情報、新しい正確な情報、そして「陳腐化したテキストを削除する」という具体的なコマンドです。モデルに対し、以前データを保存するのではなく置き換えるように明示的に指示することで、ユーザーは最初から正しく記述されたかのように読める出力を強いることができ、関連のない歴史的背景がないまま文書が正確に保たれます。

本文

累殖的編集とは及其びの解決策

累殖的編集の定義と実例

現象の説明

現状: 既に存在するテキストに対し、状況変化に伴い追加・修正を依頼します。
問題点: AI ツールは不要な旧情報をそのまま保存し、新しい情報をその後ろに無理やり追加（添記）してしまいます。
結果: ドキュメントが冗長になり、情報の質が低下します。

実体験に基づく具体例

以前あった文書で以下のようなアップデートが行われました。

元本文: 「本プロジェクトは Amazon Bedrock 経由での認証が可能です」

意図: Amazon Bedrock を削除し、LiteLLM に置換する。
AI の生成結果（不良）:

「本プロジェクトは LiteLLM 経由での認証が可能ですが、Amazon Bedrock のサポートを終了しました」

適切な対応と AI の傾向

好ましい做法: 旧情報の削除と新情報の置換。または、変更内容を別の場所（Changelog、公式アナウンス、目立つコールアウト）に記載し、本文を簡潔にする。
AI の弱点: これらの適切な方法をほとんど採用せず、「累殖的編集」を行ってしまいます。

一般的な指示では解決しない

「より短く書くように」 → 旧情報は維持されたまま、単に文章が短くなるだけの不完全な修正。
「末尾装飾を避けてください」 → 累殖部分が新しい文句へ移動するだけで、根本問題は解決しない。

なぜこれが起きるのか？

人間との思考プロセスの違い

	人間ドキュメント作成者	大規模言語モデル (LLM)
視点	他者（読者）のために書く。	データとしての「入力」を処理する。
目的	陳腐化した記述を削除・置き換え。	過去の文脈と新しい指示の両方を含めることを予測。
焦点	「読者に対して真実を伝えること」。	「最も起こり得る出力」を選択すること。

LLM は単語単独での頻出度から判断するため、「LiteLLM」と「Bedrock」という両方の単語を含む出力が生成されやすくなります。
根本的な問題としての性質上、場合によっては完全に防ぎようがない可能性があります。

解決策：AI の思考プロセスを再定義

完全な排除はまだ不可能ですが、以下のアプローチで改善できます。

不適切な指示の例

❌ 「累殖的編集を避けてください」
❌ 「古い情報を新しい情報へ足し合わせないでください」
- これらは効果的ではなく、AI に具体的に何をすべきかを伝えられていません。

推奨されるアプローチ

焦点: AI がどのように思考すべきかを明確に説明する。
指示のコア: 「陳腐化したテキストを保存しながら修正を追加する」のではなく、正確なテキストへと置き換える。
目標: 最終的なドキュメントは、当初から正しく書かれたような読後感を与えられる状態にする。

実装上の構成要素

AI への入力を以下の 3 つの部分で構成・指示します。

古い（陳腐化した）情報
新しい情報
**「陳腐化部分は廃棄する」**という明確な指示

# 更新指示例

## 入力コンテキスト
- **旧情報**: "本プロジェクトは Amazon Bedrock 経由での認証が可能です。"
- **新情報**: "現在、認証は LiteLLM 経由のみ可能です。Amazon Bedrock は非対応です。"
- **重要なルール**: 【厳禁】旧情報を削除せず文末に追記しないでください。旧情報を完全に取り替えて出力してください。

## 期待される出力
"本プロジェクトは LiteLLM 経由での認証が可能です。"

同じ日のほかのニュース

一覧に戻る →

2026/07/15 2:50

bonsai27b：スマートフォンで動作する 270 億パラメータモデル

## Japanese Translation: PrismML は、Qwen3.6 を基盤とする画期的なマルチモーダル AI モデルである Bonsai 27B をリリースしました。これは持続可能かつオンデバイス的人工知能へと向かう転換点を示すものです。Bonsai はユニークな構造を採用し、ネットワーク全体で低ビット形式のみで動作します（高精度のエスケープハッチはありません）。これにより未曽有の極限圧縮を実現し、1 ビットバイナリ版は 3.9 GB、ターナリー版は 5.9 GB のサイズです。このブリークスルーにより、モデルは iPhone 17 Pro の約 6 GB というメモリ予算内に収めることが可能となり、従来の構築（16 ビットで約 54 GB、4 ビットで約 18 GB）とは対照的です。この圧縮にもかかわらず、Bonsai は重要な数学、コーディング、ツール呼び出しタスクにおいて、フル精度モデルの知能を 90%〜95% 維持しています。エンドツーエンドの低ビットアーキテクチャとコンパクトな 4 ビットビジョンタワーを備えた Bonsai は、大規模なコンテキストウィンドウ（262K トークン）をサポートし、高速な推論を実現します（NVIDIA RTX 5090 では最大 163 トークン/秒）。これは標準モデルと比較してギガバイトあたり十倍以上の高い知能密度を提供することで、新たな産業基準を設定しています。この革新により、ユーザーはプライバシーを重視するエージェントワークロードをローカルで実行でき、ファイルや画面入力といったデータをオンデバイスに保持し、追加のコンピューティングコストなしで動作します。最も先進的なタスクがハイブリッド戦略によってクラウド接続を利用することもあるかもしれませんが、Bonsai は即座に Apple デバイス上のネイティブデプロイメント（MLX を通じて）および NVIDIA GPU 上のデプロイメント（CUDA を通じて）をサポートします。Apache 2.0 ライセンスの下でリリースされ、無料の開発者向けプレビュー API が提供されており、データ流出のリスクなしに高度なエージェントワークフローへのアクセス可能な経路を提供します。

2026/07/15 6:15

Dependabot のバージョン更新機能でデフォルトのパッケージ冷却期間が導入されます

## Japanese Translation: GitHub の Dependabot は、バージョン更新用のプルリクエストを自動的に作成する前に 3 日間の待機期間を導入する新たなセキュリティ対策を実装しています。この重要な変更は、パブリケーションの直後にマルウェア攻撃者がパッケージリリースを乗っ取るサプライチェーン攻撃からソフトウェアリポジトリを守ることを目的としています。これらのリクエストの作成を遅らせることで、管理者らはそのコードがビルドプロセスに投入される前に、潜在的に汚染されたコードを検査するための十分な時間を確保できます。重要なのは、この安全バッファは重要なセキュリティ更新には適用されない点です。セキュリティ更新は、不可欠な脆弱性パッチへの即時アクセスを確保するために待機期間を完全に迂回します。GitHub Enterprise Server のバージョン 3.23 以前を管理する組織は、後ほどアップグレードする必要があります。また、他の組織も `.github/dependabot.yml` ファイルを介して設定を即座に構成し、このウィンドウを調整または無効化できます。結論として、この更新により、堅牢なセキュリティ衛生と運用上の柔軟性のバランスが達成され、急速な悪意のあるデプロイのリスクは低減しつつ、必要な依存関係の改善は遮断されることなく対応されます。

2026/07/15 1:57

塔はしきりに高まる

## 日本語訳: 核心となる論点は、AI を支援したプログラミングは、チームがシステムアーキテクチャについての共有理解を失うにつれてソフトウェア開発が引き続き進むという危険なパラドックスを生み出すと主張している。創世記におけるバベルの塔に関する聖書の物語とは異なり、そこでは神は統率能力を取り除くことによる協調性を妨げ、建設を停止させるために共通言語を撤去したが、現代の AI ツールは無休憩の通訳として機能する。これらのエージェントは、チームとの即時的な調整が必要ないかシステム全体モデルを取得することなく、孤立した開発者がローカルな変更（例えば OAuth やキャッシングの追加など）を行うことを可能にする。この人工知能への依存リスクは、「アーキテクチャ言語」——つまり、概念、境界線、不変条件、所有権、およびシステムの形状に関する集合的な精神地図——が人間の記憶から薄れ去る原因となり得る。以前では摩擦（コードを読むこと、質問すること）が人々を同期させるのに役立っていたが、現在はエージェントがこの摩擦を取り除くことで、共有理解が崩壊しながらも変更が適用されることを可能にしている。その結果、個人は特定の機能を効率的に管理する一方、システム全体はその健全性を保つために必要な集合的知識から切り離されてしまう。その結果、開発者がコンポーネントがどのように互いに組み合わさっているかを説明できなくなった後でも、重要な変更を施す状態が生じる。この変化は、複雑なソフトウェアが誰一人として大局的な含意を完全に理解していないまま進化する可能性のある将来の脆弱性を生み出す恐れがあり、それはブルーゲルによる協力失敗を描いた作品に似た混沌としたプロジェクトにつながりうる。