AI新聞

Claude Codeやbpmn.ioを使い、BPMN 2.0でAIに扱いやすい業務フローを管理する方法を解説した記事。

• BPMN 2.0のXMLで“意味”を保持しAIとlintで品質を上げる（座標の推測不要、ツール間互換あり）。
• エディタ比較：bpmn.ioはBPMN 2.0で保存、VS Code拡張あり、bpmnlint・bpmn-to-imageが使える。
• ガイドライン策定：記法の範囲（Analytic等）、タスク粒度（FL参照）、命名やレイアウトのルール。
• 静的解析：bpmnlintで開始/終了漏れ・未接続・条件漏れを検出、CIに組み込み。
• 静的では拾えない意味の誤りは、生成AIレビューで補完（ルールを読み込ませ根拠付き指摘）。
• 画像化：bpmn-to-imageでSVG/PNG/PDF、VS Codeタスク化で運用。
• 効果：レビューが業務の中身に集中し、DFDとの突合も行いやすくなる。

AIがコード作成やテストを大幅に自動化し、開発の詰まりどころが「工程の流れ」と「学習の仕組み」に移っている。これに対し筆者は、トヨタ生産方式を手がかりに、ムダの削減、小さなロット、標準作業、見える化、現場重視を開発に当てはめ直すべきだと述べる。

具体的には、プロンプトやレビュー基準の標準化、WIP（同時作業の数）の制限、エラーで止まる自動チェック、短いリードタイムを守る流れ作り、継続的な改善の仕組みを提案する。結論は、AIで速度が上がるほど工程設計が重要になるという指摘で、道具選びより流れの最適化が成果を決めるという主張。

AIは「履くだけで速くなる靴」のように全員が使えば差が消える。だからこそ、同じAIを使う前提での競争ではなく、人・データ・AIをひとつなぎにする組織力が差を生むと述べる。

具体策は、社内を横断する「CARTA ZERO」という統合データ基盤で、正本（信頼できる元データ）を一箇所に定め、業務システムは標準機能に合わせ、ハブ&スポークで入替に強くし、MDM（名寄せと用語統一）で文脈をそろえること。

基盤の作り直しとAI活用は並行し、ニーズ・入出力の定義・必要データ・正解判定者がそろう業務から試す。最終的に、個の凄さでなく「組織としてブレずに再現できる力」を文化として作ることが競争優位になると主張する。

GoogleのEmbeddingGemma 2は、0.74B規模の軽量な埋め込みモデル。1つのモデルで写真・動画・音声・文字・コードを横断検索でき、声のメモから動画内の場面を探すなどのマルチモーダル検索を端末内で実現する。

量子化でPixel 11 Proでも約191〜567MBのメモリで動作し、ネット不要でプライバシーも守れる。MRLによりベクトル次元を128まで落とせ、検索用データベースを最大6分の1に圧縮できる。

コード・画像・動画で同規模帯トップ級の精度を示し、Gemma 4と組み合わせたローカルRAGに好適。オープンウェイトをApache 2.0で無償提供し、Hugging FaceやKaggleから入手できる。

若手エンジニアが現場でAIを活用すると、答えが出続けるため人に聞く判断が遅れがちになり、組織固有の前提や運用ルールの不足で迷走しやすいという問題がある。さらに「動く実装」と「保守・テスト・操作性まで含む良い設計」は別で、前提が誤っていればAIも誤る。比較や照合のように基準を渡せる作業は有効だが、抽象的な依頼はぶれやすい。

筆者は、ゴールの明確化、要件の分解、情報源の特定、誰に確認するかの判断、AI回答への疑義、設計理由の言語化といった力が重要だと説く。結論は、AIを使うほど「何をAIに任せ、どこで人に確認し、自分でどう判断するか」を磨く必要があるという指摘である。

Claude Haiku 5.5への置き換え可否を、役割別に検証し定義も見直した記事。

• テスト実行役はHaiku/lowで十分。短い定義と単純作業なら安く速い。結果を決まった形に写すだけならHaikuで十分。
• 調査役は質はSonnetと同等だが範囲を広げがちでトークンが増える。費用は概ね1/10以下。100,000トークン超で単価5倍に注意。
• 調査役は「事実」と「推論」を分け、検索ログと未確認範囲を必ず書かせる。呼び出し元で抜き打ち確認する前提に変更。
• 実装役は判断と確認が必要なためSonnet/highを継続。Haikuは「完了」と誤報することがある。
• effortは役割定義に固定で十分。呼び出し時に都度変える利点は小さい。
• 定義も改修。テスト役をcommand-runnerに拡張、報告にStatusやDID NOT RUNを追加。実装役はspec-coderに改名し、未実施・逸脱・検証手順を自己申告させる。

ClaudeやJevを使い、ベクトル検索なしでGraphRAGを組むコツを解説した記事。

• はい/いいえの判断を専用モデルに任せてRAGの探索を制御する。文章生成はLLM、判断はJevに分担してコストを大幅削減（登録抽出は約20〜30分の1）。
• エンティティの台帳（マスター）を用意する。種別・関係は粗く設計し、「つながっているか」だけ分かればよい粒度にする。
• 前処理で候補を絞る。本文に名前・別名が含まれるものだけJevに聞くなどで、総当たりを避けトークンを7万→約6,400に圧縮。
• 判断ポイントを6箇所に限定し、閾値で進む/止めるをif文で制御。「もう答えられる？」の判定で不要なホップを止める。
• 数値スコアを活用し、同義表現や曖昧な指示語からの特定（例：「探偵のおじさん」→毛利小五郎）を安定化。
• エンベディング起点やLLM判定のGraphRAGと比較し、ホップが必要な質問でJev方式が精度・コスト面で有利。
• 失敗例と限界：マスターにない固有名は辿れない、答えのない質問は高コスト、絞りすぎると「つなぎ文章」を落として精度低下。
• 実務ではマスター整備と閾値調整がカギ。漠然質問は通常RAGや広域検索と併用し、用途を選んで使うのが現実的。