AI新聞

会計事務所の単純入力はAIで消えるのでは、という問いに対し、実務ではクライアント側の紙・PDF運用が根強く、AIの仕訳精度もまだ甘いため、人の手が要るという指摘が多い。現金領収書や提出物という「物理の成果物」を求める需要も残る。

結局、入力係はAIが出した仕訳を検証・補正する役割に置き換わるだけで、ゼロにはならないという見方が主流だ。むしろ人件費や料金体系の見直し、アナログな顧客へのサポートなど、仕事の中身が変わっていく。

将来はデータが最初から統一形式で来れば大幅に自動化できるが、そこに至るまで時間がかかる。現場では当面、人とAIの分担で回す現実解が続くといえる。

• NodeとEdgeが何を表すかで役割を分けると、エージェント設計の混乱（「全部ナレッジグラフ問題」）を避けられる。
• 意味を保持するのは1種のみ：ナレッジグラフ（エンティティと関係）。GraphRAGは検索補助で、意味そのものの固定とは別。
• 実行を支える4種：タスク（何をやるか）、DAG（どの順で処理するか）、ワークフロー（承認や差し戻しの業務ルール）、ステート（今どんな実行状態か）。
• Markdownウィキは叙述には強いが、同一IDや関係の型、承認ルール、現在状態などの「型」を保持できずに混在しやすい。
• ループすべき所とDAGで順序固定すべき所を分けると、無駄な試行やトークン浪費を抑えられる。
• LangGraphは状態追跡に強く、Dify/n8nはSaaS連携と業務フローに強い。KGはNeo4j等で別レイヤに置く、など役割で道具を分担するのがよい。

企業でAIエージェントの導入が進む一方、指標の定義や業務知識がWikiやSlackに散らばり、統一して参照できないのが問題だと指摘する。解決策として、OKF（YAML付きMarkdownで1概念1ファイルにまとめる保存形式）で知識を梱包し、RAG（検索してLLMに渡す取り出し方）で引き出す流れを提案する。

OKFのtypeやtagsはRAGのメタデータフィルタとして効き、ハイブリッド検索で精度とコストが向上する。両者は競合ではなく補完関係にあり、gitで配れてベンダーに縛られない共通基盤、つまり全エージェントが同じ知識を参照する「会社のOS」を作れると述べている。

• 品質保証はテストに寄せる。実装言語に依存しない大量テストを用意し、スキップや削除を禁じる。テスト外の振る舞いは盲点になるので観測範囲を広げる。
• レビューは文脈を分離。実装したAIとは別のAIが差分だけを見てあえて粗探しする。思い込みを避けるための文脈を共有しない敵対的レビューが効く。
• 問題が出たら出力ではなく規範や手順のファイルを直す。言い訳ワークアラウンドの禁止や危険コマンドの禁止など、ルールで再発を止める。
• 役割を分けた単位ループ（実装者・レビュアー・修正適用者）で回す。並列度が低くても有効。
• 適用は「同じものを同じく作る」仕事向き。言語移植やAPI差し替えなど、正解が外にあるタスクに強い。設計の委ねは別物。
• 前提は強いテスト資産と実行時間。特にフロントは遅く不安定になりやすいので、レビューは「触って確かめる」粒度へ縮める。
• コストは大（今回は64並列で約16.5万ドル）。ただし運用の骨格は小さく真似できる。基準と手順の外部化、レビュー分離、小規模試運転から始める。

AI-DLC Workflows 2.0 は、AWS がOSS公開した「AI中心の開発ライフサイクル」を実装した仕組みで、AIが計画と実務を進め、重要判断は人間が承認する流れを徹底します。画一的な重い手順や、人間の監督が薄れる問題を避け、スコープと深さで作業量を自動調整します。

コアはMarkdown+YAMLで32ステージ・11エージェントを定義し、ビルドしてClaude Code・Kiro・Codex CLIなど複数環境へ配布する「one core, many harnesses」設計。エンジンが次手順を決定論で計算し、コンダクターが実行、承認ゲートとセンサー、学習ループでチームの知見を蓄積します。要するに、決定はコード、判断は人間という設計です。

v2はGA Previewのため変更の可能性があり、本番は安定版ブランチ推奨です。

• GitHubで公開された一流エンジニアの .claude/skills から、良いSkillの共通原則を抽出。
• descriptionで呼び出し可否がほぼ決まる。先頭に効くキーワードを書き、何を・いつ使うかを三人称で明確化。手順の要約は書かない。
• descriptionのトークン枠は全体の約2%。Skillが多いと1つあたりの枠が減るため、冗長さを削る。
• SKILL.mdに全部を書かず、詳細は別ファイルへ逃がす「段階的開示」。多段参照は避ける。
• 分岐ごとに必要な情報を切り分ける。共通はインライン、特定分岐は参照先へ。
• 呼び出し設計を決定論的に。副作用のある操作はuser-invokedにし、自動発火を止める。
• user-invokedが増えたら、案内だけするrouter skillで束ねる。
• Addy流「言い訳テーブル」で、AIが手順を省く常套句を事前に封じる。Red Flagsや検証チェックで締める。
• 有名2リポを同時に「ルーター」として入れない。衝突で挙動が不安定になる。
• 信頼できる出所からのみ導入し、中身を読んで検証。Skillは書いて終わりではなく、育てて廃止も管理する。

• 導入しないリスクも同じ土俵で評価（人材流出や競争力低下）し、議論を「どう安全に導入するか」に切り替える。
• 情報漏洩の経路を2つに分けて対策する（チャット入力／外部ツール連携）。
• チャット入力はEnterprise契約で「入力が学習に使われない」ことを確認する。
• 外部ツール連携は既存の守りで制御できると検証する（通信先を絞るプロキシ、メールの送信先制限、外部送信の承認フロー）。
• 最後の防波堤として「許可された操作だけ実行可」のリスト運用を敷く。新規操作は事前承認。
• 実行型エージェントは、個人の効率化用途は緩やかに、業務フローに組み込むものは台帳で管理し可視化する。

AI開発で「ループエンジニアリング」は、モデルを囲う足場＝ハーネスそのものの設計ではなく、「そのハーネスをいつ・どの頻度で・誰が回し、合格を誰が決めるか」という自律運転の設計だ、と位置づけ直す。この記事は、その要である実装は安いモデル・検証は強いモデルの使い分けが、GitHub Copilotでも実現しやすいと主張する。

Copilotはメイン会話のモデル自動切替は弱いが、Autopilotや/fleet、スケジュール実行、サブエージェント単位のモデル固定で骨格は十分。注意点は、理解の置き去りやトークン費の膨張で、検証を別モデルに分離しつつ上限やレビューを必ず入れるべきだとしている。

大規模言語モデルの中で何が起きているかは見えにくい。AnthropicはClaudeの内部に、人の意識研究でいう「グローバルワークスペース」（多くの情報が一度集まり全体に共有される場）に似た構造があると報告した。

内部表現を解析し、出力に現れない推論過程や中間メモを示すことで、表に出ない思考の可視化に成功したという。これにより、モデルの安全性検証や方針の調整、虚偽や錯覚の早期検知に役立つ可能性がある。一方で、意識そのものを示す証拠ではなく、再現性の検証が必要だと述べている。

BunはZig製ゆえにメモリ管理絡みの不具合が多く、長期の保守性を重視してRustへ全面移行した。移行ではClaude Codeを使い、エンジニア1人が監視しつつ自動変換を回し、53万行をわずか11日でテスト合格まで持っていった。筆者は、Rustのコンパイル時の安全性で再発バグを抑え、開発速度と安定性を両立できると述べる。

一方でZig作者はBunの開発姿勢を批判し、ファジング（ランダム入力で不具合を探すテスト）未実施を指摘したが、Bun側は継続実施の証拠を示して反論した。要するに、AI支援で巨大コードを短期に他言語へ移植できる現実性と、その裏での品質管理の是非が論点となっている。

aws-samplesのsample-agent-cost-benchは、コーディングエージェントを「同じタスク・同じ設定」で走らせ、コストと品質を同条件で客観比較できるベンチマークツール。モデル横並び（model-compare）とエージェント横並び（cli-compare）の2モードに対応し、隠しテストでの採点、実行ログからの自動コスト抽出、途中経過のチェックポイントなど公平性と実用性の仕掛けが揃う。

同梱タスクに加え、自分のGitHubリポジトリとテストでも評価可能。記事の実測では、Sonnet 5とOpus 4.8は品質同等だがOpusは約1.7倍高コスト、Haiku 4.5は失敗を含めても最安という示唆が得られた。

• 手順: ChatGPT Images 2.0でスライド風画像を作り、GPT-5.6 Solに渡して編集可能なPPTXへ再構築。ChatGPTのWebだけで完結。
• 役割分担: デザイン＝Images 2.0、実装＝Solで、デザイン品質と編集可能性を両立する2段階生成。
• 画像生成のコツ: 16:9・1枚1スライド、タイトル/リードの位置固定、余白固定、配色/フォント統一、要素を重ねすぎない、フッター等は入れない。
• レイアウト原則: リード文はスライド唯一の主張として上部に2行、コンテンツは8列グリッドで構成、下部に総括文を置かない（表やプロセス等の作法も明確化）。
• 変換プロンプトの肝: 画像を貼るだけにせず、テキストはテキストボックス、図形は図形、表は表として再構築し、最終PPTXを必ず出力する旨を明示。社内テンプレがあれば一緒に添付。
• 直接PPT生成しない理由: 直生成は無難な配置に寄りやすい。画像で先に見た目を作り、Solで忠実にPPT化すると一発で高精度に仕上がる。

AIの内部で起きている「J空間」（学習の過程で自然に生まれた、概念が活性化する領域）を可視化するデモ「Jレンズ」を試せる。チャットに質問すると、右側に活性化したフレーズが時系列で並び、次トークン生成の裏で何が活性化しているかを見える化できる。

各語の直前にどのフレーズが強く反応したかも追跡でき、「スマート」→「フォ/phones」などの連想の流れが分かる。QwenやGemmaなど複数モデルに対応。人間の思考や感情を示すわけではないが、モデルの「連想の道筋」を直感的につかめるのが特徴。