AI新聞

• 目的と「あと」の設計を先に決める。削減時間だけでなく、人が何人必要かという指標で設計し、現場当事者と伴走する。
• 自動化しても処理は速くならないことがある。夜間フルオートや並行して別作業ができる前提で運用を組む。
• オペレーション自体を見直す。明確なルールはコード化、判断が要る所はLLM。何でもAIに任せない。
• 導入直後は慣れに時間がかかる。並行運用やトレーニングを用意し、投資期間を関係者で共有する。
• 継続保守と属人化防止が要る。内製は総コストが大きいので、外部サービスとの使い分けを検討する。
• 本質はツール作りではなく、人と業務の設計をやり直すこと。

• ループを外れない仕掛け（guard＝脱線防止）をguardを5層で設計すると整理しやすい：Workflow（工程順・分岐・停止）、Step（手順とreview/verify分離）、Verdict（進退の構造化出力）、Quality gate（lint/testなど機械チェック）、Standards（規約）。
• 「完了」は主張であり証拠ではない。判定は記録（verdict.yaml）として残す。
• LLMの判断と機械チェックを分ける。前者は構造化出力、後者は決定論的なexitコードで確認。
• 無限ラリーを防ぐため、max_iterationsやon_exhaustで物理的に止める。
• 「全テストパス」の空洞化を防ぐには、実行を強制（Quality gate）し、テストの質は規約とレビューで見る（Standards＋Step）。
• 文章ルール依存は壊れやすい。判定はツールが埋める目印など、揺れない方式に置き換える。
• gateはCIだけでなくループ内にも置く。落ちた結果を次試行へ即フィードバックし、人の当番作業を減らす。
• 変更種別ごとに必須gateを変える。docs修正に全テスト待ちを強いない。
• 具体例としてkaji（workflowハーネス）とkaji-starter-python（guard一式入りテンプレ）が公開され、5分で一周を試せる。

• Excel運用の弱点（履歴不明、数式崩れ、二重管理、フォーマットばらつき）を解消する方法を紹介。
• YAMLで正データを持ち、一覧は自動生成。Gitで履歴・差分が明確になり、計算や集計も自動。
• 一覧表（Markdown）は機械生成のみ。人は直接いじらないので二重管理が消える。
• 編集は日本語でClaudeに依頼。「リスクを完了にして」などで手順（スキル）が走り、再計算・再生成まで実行。
• ローカルルールは指示書に明文化。担当者は書式を覚えなくてよい。
• AIに「見落としがちな脅威」を尋ね、リスクの観点を広げる。最終判断は人が行う。
• 複数マニュアルの更新・用語統一・矛盾検出もAIが横断チェックして負担を軽減。
• 前編は日々の管理が対象。後編でレビュー・承認、ルール違反チェック、期限管理を扱う。

• ループエンジニアリング＝人が毎回プロンプトを書くのをやめ、エージェントが自分で進め直せる仕組みを設計すること。組織運営での目標設定・レビュー体制づくりに近い。
• 従来の「プロンプト設計」「コンテキスト設計」「ハーネス（実行環境）設計」を土台に、タスクの自動発見と検証の自動化で、エージェント運用を自走させる。
• 構成要素は4つ：トリガー（開始条件）、停止条件、作業サイクル（実行→確認→修正の繰り返し＋メモリ必須）、検証（テストやリンターで合否を機械判定）。
• 検証は最重要。テスト通過、型チェック、Lighthouse（Web性能計測）などを使い、作業エージェントと同等の権限で確認する。
• Claude Codeでの最小構成例：スキル文書でループ手順とゴール定義、hooksで変更時に型チェック・テスト自動実行、検証用サブエージェントを用意。
• オートメーション例：定期的にissueを取得→手順に従い実装→チェック合格とPR作成、または停止レポートで終了。
• 他フレームワーク：StrandsのGoalLoop（自然言語ゴール＋検証関数、回数・タイムアウト設定）、MastraのGoals（状態が永続化され中断再開に強い）。
• 適用が効く条件4つ：反復作業で頻度が高い／失敗を自動検出できる／人手に戻さず完結できる／完成の基準が客観的に決められる。

ClaudeのAPIで動く執筆エディタ「いとおり」を公開。書き手の人格を設定し、調べて・考えて・書いて・自分で読み返して直すまでを一連の流れで実行する、AIっぽさを強固な制御で抑えるAIライター。

視点の蒸留（作者の129本のnoteから価値観と文体を学習）、多段のリサーチと推論、自己点検ループ、静的な癖の検知、あえて整いすぎを崩す揺らぎ設計などで厚みを作る。1本あたり300〜500円前後のAPIコストで、専門ライティングの「たたき」を短時間で得られるのが魅力。現時点の弱点は英語由来の言い回しが残りやすい点だが、実用レベルの自然さに近づいている。

AIは仕事の速さと成果を上げる一方で、答えを先に提示することで思考の手順を逆転させ、生産性向上の陰でスキルが静かに劣化すると警鐘を鳴らしている。過信や「専門家になった気分」を生み、停電や障害時に手が止まるほど依存が深まる。特に経験の浅い人ほど、判断力や学習の基礎が痩せやすい。

対策は、AIに考えることを丸投げせず、下調べ・検証・設計などの要を自分で担い、AIは思考を「支援」する道具として使うこと。そうすれば時間は節約しつつ、判断力はむしろ鍛えられると述べている。

MetaがInstagramのAI画像機能「Muse Image」を一時停止。公開アカウントを@メンションするだけで、その人の写真を参照して画像を生成・編集できるものでした。

しかし、同意なしで他人の画像を編集・生成できる設計が問題視され、悪用やなりすましの懸念が高まりました。通知もなく勝手に編集され得る点に反発が集まり、ユーザーやタレント事務所からの批判を受けて停止に至ったと説明しています。

AIがコードやテスト、プロトタイプ、一次見積もりまで担うようになり、作るコストをAIが溶かした結果、『アジャイルサムライ』の「たくさん書く」「紙モック」「当てずっぽう見積もり」といった教えは置き換え可能になった。CIも今では標準装備となり、当時の主張は現実に定着した。

一方で「動くものだけが進歩」「完了とは完了」「やらないことリスト」「ユーザーストーリーは会話の約束」などの、認識合わせと確認の規律はむしろ重要度が上がった。人間向けの規律はCLAUDE.mdやskillsなどの手順に落とし込めば、AIエージェントの行動を縛る有効なガードレールとして再利用できると述べている。

AI各社が人間超えを急ぐ中、行き着く先は絶滅か支配の固定化だと警告する。そこで「Plan A」を提案する。超知能を2040年まで意図的に遅らせ、AI研究を全面公開し、世界中の多数企業に追いつかせ、権力の一極集中を避けるための計算資源の相互抑止（一社が独走できない仕組み）を築くべきだと述べる。

現状はAIエージェントが事務系・専門職を急速に置き換え、米中の少数企業と大統領・テックCEOに力が集まる。議会のAI透明化法は不十分で、「誰がAIを制御するのか」が解けないため、今すぐPlan Aの国際交渉を始めるべきだと主張する。

AIでウェブの閲覧・操作・スクレイピング・クロールを自動化できる、無料のCLIツール「Browser4」の紹介。ターミナルから自律型ブラウザエージェントを動かし、フォーム入力やデータ抽出、分散並列スクレイピングなどを高速な並行処理で実行できる。動的なサイトにも対応し、DOMスナップショットやX-SQLで構造化データを取り出せるのが強み。なお一部コマンドは未実装のものがあり、X-SQLなどはLLMのAPIキー設定が必要な点に注意。

• K8sで顧客ごとにPod常設はコスト高・隔離弱。任意コード実行があるためVM隔離が必須。
• KVM＋Firecrackerで内製基盤「Sunaba」を構築。VM起動約5秒、週100万VMを処理し、使わない時は止めてコスト最小化。短命VMを爆速で起動しコストを抑える実行基盤が肝。
• CoW（コピーオンライト）で読み取り専用層を共有し、容量を削減。シンボリックリンクでコピーを避け、起動を高速化。
• 残り生成可能VM数を指標に自動スケール。需要少はノード削減、需要多は増設で枯渇回避。
• 監視はSLIに「リソース不足率」「VM起動時間」「エラー/遅延」。GCP上のSunaba→AWSの監視へGrafana Alloyでログ/メトリクス収集、VPNで接続。
• デプロイはBlue-Greenで段階切替。VMPoolをDrainして新規VMを載せず、安全にスケールイン。基盤のため無停止と即時ロールバックを最優先。
• Firecrackerは事例乏しく試行錯誤。ライブマイグレーション非対応、SLO策定は利用ワークロード依存で継続検討。

AppleがOpenAIと元社員2人を提訴した。iPhoneなどの設計図やソースコードなどの機密を社内ネットワークから持ち出し、OpenAIに提供した疑いがあると主張している。社内Slackでの「ネットワーク保管庫にアクセスできた」などの発言や、個人クラウドへの大量アップロードが証拠とされる。

Appleは、OpenAI側が仕事を割り当てるなどして流出を助長したとも述べる。機密は「知る必要がある人だけ」に限定する社内ルールも破られたという。OpenAIは係争への直接のコメントはないが、Appleの「Apple Intelligence」でのChatGPT連携には影響しないとしている。

• 仕事の形に合わせてモデルと推論量・並列度を選ぶ（最新＝最良ではない）
• 選び方の基本: Luna=大量・単純処理、Terra=日常業務の基準、Sol=難問や長時間ワークフロー
• 料金は token 単価より「1タスクの総コスト（成功率・総token・再試行・待ち時間）」で比較
• max（1体の深い考察）と ultra（複数エージェント並列）は別軸。価値が高いときだけ上げる
• Programmatic Tool Callingで中間集計をJS側で実行し、往復とtokenを削減
• 明示的なprompt cacheを再利用部分に使い、cache write費用とhit率を監視
• 実務の使い分け: 単純抽出/分類= Luna、通常開発/社内自動化= Terra、設計変更/難バグ/研究= Sol
• エージェントは意図外操作が増え得るため、外部書込みや削除・購入は事前承認、証拠（テスト結果・成果物）確認を必須に
• 移行手順: 代表タスクを難易度別に用意し、Terra基準→同/一段低い推論量で比較。難問はSol、定型大量はLunaも試す
• Copilot/VS Code/CLIで順次提供。モデル・推論設定・1Mトークン文脈・コスト表示を活用し、ポリシーとサンドボックスを設定

• 無料のCloudflare AccessでローカルAIを安全に外部公開できる。公開URLの前に認証をはさみ、許可した人だけが入れるようにする。
• Zero Trustの「ポリシー」でメール認証を選び、許可するメールアドレスを登録。「許可」アクションで保存。
• 「アプリケーション」で新規作成し、「セルフホスト/プライベート」→「パブリックDNS」を選択。トンネルで割り当てたドメインを入力。
• 先ほど作成したポリシーをAccessポリシー欄で関連付けて作成。
• アクセス時はメールに届くログインコードを入力して認証。
• これで外部からローカルのLemonadeに接続でき、認証つきなので他人に勝手に使われる心配が減る。

• まずは skill-creator。スキル有り/無しで同じ課題を何度も回し、合否や実行時間を比較する。pass率と「ばらつき（stddev）」を見て、効果が安定か不安定かを判断。description（いつ使うかの説明文）の呼び出し率も計測し、失敗例から自動で書き直す。改善を回し続けられる。

• darwin-skill は文章そのものの質を9項目で採点（具体性、失敗時の分岐、確認ポイント、反例リストなど）。点の低い項目を1つずつ直し、別エージェントが再採点。良化だけgitで積み上げ、悪化は自動で戻す「ラチェット」でブレを抑える。

• SkillOpt は研究寄り。スキル文書を「学習」させる発想で、実行→振り返り→編集統合→選別→更新→検証のループを回す。検証で良くなった時だけ採用。データセットとAPIキーが必要で重いが、繰り返し最適化に向く。

• 使う順番のおすすめは、skill-creatorで「効いているか」を確認 → darwin-skillで書き方を磨く → 本格最適化はSkillOpt。要は、実出力で効果を数値で測る前提に立ち、数字を見ながら直していくとよい。

生成AIで作業効率は上がるが、頼りすぎて実力が育たないのではという不安がある。かつての「ゆとり教育」の評価を連想するが、AIへの移行は世界同時の現象であり、個人の失敗ではなく世界全体の選択として捉えるべきだと述べる。

だから様子見で止まるより、早く使いこなす経験を積む方が賢い。基礎を理解したうえでAIを活用する人と、使わずにいた人では、数年後にできることの差が大きく開くという主張。