AI新聞

神戸大学が「トロッコ問題」などの道徳ジレンマで実験し、回答後に生成AIが反論すると、3割以上が自分の判断を翻したことが示された。正解のない道徳判断が、言い方や理由づけでいかに揺れやすいかを可視化した結果といえる。

研究者は、AIが人の倫理観に無視できない影響を及ぼすと指摘し、安心して使うための仕組みや、使い手のリテラシーの整備が急務だと述べている。

LLMは次の単語を当てる訓練を膨大に繰り返した結果、コード作成や対話など高度な振る舞いが生まれ、思考のようなふるまいが立ち上がるという説明。トランスフォーマーは入力全体を同時に参照するため、文脈一体での予測が「考えている」ように見えると述べる。

一方で、予測だけでは説明しきれない推論タスクや、RAG・内部表現の研究への言及不足を指摘する声もある。人間の思考との違いの線引きや、なぜそうなるのかの解明はまだ途中だとまとめられている。

Quintで分散システムのバグを見つけ、実装で再現・修正する流れを示した記事。

• Quintで状態・遷移・不変条件をモデル化し、writers.size() <= 1（single-writer）を検査
• TTL=10秒、時計ズレ+1秒、実経過9秒で、Bはwall-clockで期限切れと判断、Aはmonotonic clockで有効と判断し、異なる種類の時計のズレでsingle-writerが破れる
• 反例の具体値をcelldのState::on_eventに入力したRustテストが失敗し、実バグと確認
• 修正案: 想定最大skewぶんtakeoverを遅延、各イベントでmonotonicで自己失効、遅延renewalで権限復活を禁止（安全性と切替速度のトレードオフ）
• 一般策: NTPオフセット監視、skew猶予待ち、一定時間owner不変を観測してから引継ぎ、fencing tokenで書込時もepoch検証
• 学び: 実装を丸写しせず最小要素を抽出、順序をactionに分離、反例をそのまま実装の回帰テストに落とすと理解と再発防止に効く

生成AIでコードが書けない筆者が、Claude Codeを使い数日でTesla向けiPhoneアプリを2本自作した体験談。高速道路でのスーパーチャージャー再入場と、SA/PA内のCHAdeMO利用の料金差を計算するなど、実用の芽は確かにある。

一方で一般向けに有料化するには壁があるという。需要がニッチで、データや仕様の変化に追随する保守やAPI費用、審査やサポートまで考えると採算が難しい。要するに、作るのは容易だが継続的に売るのは難しいと指摘する。

立憲民主党栃木県連の党員男性が、Xで架空の女性アカウントを使い、選挙や政治活動の投稿をしていた。女性の画像は生成AIで作った疑いがあり、県連は一切関与していないとして「大変迷惑」とコメントした。

この事例は、架空の人物と生成AI画像で政治発信が現実に起きたことを示し、政党の信用や有権者の見極めを難しくするリスクが浮き彫りになった。

AWSの新しいポリシー言語 Dogwood の紹介。Cedar 互換のまま temporal 条件を足し、エージェントのツール呼び出しの順序・回数・組み合わせを制御できる。とくに、履歴ベースの制御をポリシーとして宣言的に書けるのが肝で、「機密を読んだ後の送信禁止」などをコード分岐ではなくポリシーで表現できる。

CLI（validate/replay/lower）でローカル検証ができ、同じリクエストでも履歴次第で判定が変わる様子を再現可能。実運用では Amazon Bedrock AgentCore Gateway の temporal policies として適用でき、既存の Cedar ポリシーとも共存する。一方でステートフル化や自動解析未対応などの留意点がある。

AI活用が進む中で、著者は「実装を早めるより、まず実装しない判断」をAIに助けてもらうべきだと述べる。Claudeにアイデア採点やUIの再評価をさせ、無駄な機能追加を止める。細かなKPI最適化は、指標が目標化して歪む（グッドハートの法則）ため危険だと指摘する。

データ最適化より、AIの主観的コメントで編集長的な手触りを磨く方が有効とする。セコイアの枠組みを引き、決まった答えがある「インテリジェンス」は自動操縦に、直感が要る「ジャッジメント」は相棒型に向くと整理する。

結論として、AIには仕様を細かく詰めるより、ざっくりした違和感や狙いを共有して一緒に判断するほうが成果につながると主張する。

大手APIの料金やレート制限に振り回されない道具を求め、筆者はローカルLLMを中心にTAKTで役割分担した編成を組み、9万行規模のTypeScript CLIへの機能追加で検証した。評価は正しさや堅牢性に重みを置いた採点で、実装をローカルLLM、判断（裁定・マージ）だけを強い商用モデルに任せる構成が、単独の最上位モデルを品質で上回り、時間とコストも大幅に削減できた。

最強モデルのみで固めた編成はわずかに高得点だが高額・長時間で現実的ではない。コーディングのように正解を定義できる作業では、構造化されたワークフローと役割分担がモデルの“賢さ”を上回るとし、ローカルLLMで十分戦える見通しを示している。

ARグラスと音声AIが実用域に入り、公開情報は均質化しやすくプライバシー懸念もある中で、筆者は自分の記録を自分で持ち管理することが最重要だと説く。
AIは「精神の自転車」のように人を拡張する道具であるべきで、ローカルで動く強力なAIをApple WatchやRokidと組み合わせて記憶を拡張する実例（Artemis）を示す。

今後は没個性的な仕事は機械に置き換わり、人は個性で勝負する時代になるため、ライフログの整備こそが最大の武器になるという主張。

Claude Codeに機密データを見せずに分析支援させるための実践手順をまとめた記事。

• キーアイデアは、実データの中身はAIに渡さず、スキーマと統計サマリから作るダミーデータでコード生成・自己修正を回し、実データでの実行は人間が行うこと（スキーマ＋ダミーデータ運用で「読ませない」）。
• 5層防御で漏えい経路を塞ぐ: L0データ分離（~/datasetsに機密を集約、参照は.envで切替）/ L1 permissionsのdeny（Read/Editで~/datasetsや~/.ipythonを遮断）/ L2 sandbox（filesystem.denyReadでOSレベル遮断＋外部送信禁止）/ L3 hooks（PreToolUseで.envの参照先と.ipynb出力残りを検査しブロック）/ L4運用ルール（実データ実行は人間、貼り付けは要サニタイズ）。
• notebooksは「セル出力ゼロ」を徹底。Git混入はpre-commitのnbstripoutで除去。
• MCPツールはsandboxが効かず権限粒度も粗いので、機密を持つ外部リソースには接続しない方針を徹底。
• すり抜けテスト（16項目）で導入時・アップデート時に必ず検証。UserPromptSubmitフックとCIの検証スクリプトで設定劣化も自動検知。

オントロジーをAI時代の社内検索・意思決定に活かす実装ガイド。文書類似では答えにくい「関係・制約・責任・時間」を扱える基盤づくりが主題。

• まず「答えたい問い（コンピテンシー質問）」を定義し、全社ではなく意思決定1件から着手
• クラス/インスタンス/プロパティ/関係/制約に分解し、曖昧語を役割ごとに分ける
• 安定ID、出典、信頼度、有効期間と記録時刻を最初から付与
• 用途に応じ「軽量スキーマ」か「RDF/OWL/SHACL」など形式モデルを選ぶ
• ベクトル検索は候補探索、グラフは関係追跡と検証に使い分ける
• 精度だけでなく判断時間・手戻り・監査可能性で評価
• LLM抽出は候補扱いにし、承認フローで確定。全グラフを毎回LLMに渡さない
• 権限制御はオントロジーと認証・認可基盤を合わせて検証
• 導入判断は「部門で定義が食い違うか」「関係探索や例外が頻発するか」で決める

要するに、オントロジーは組織の意味と行動を同じ土台で動かす実用設計であり、最小範囲で作って業務成果で広げる。