AI新聞

自作の分析エージェント開発は、UI・認証・メモリーなど本質でない作業が重く、Claude/ChatGPTに劣る体験になりがちだと気づき中止。必要部分だけをMCPとして作り、汎用AIに接続する方が早く質も高かった。

そして最大の学びは、良い分析体験の肝はエージェントではなくデータ基盤にあること。注目指標の定義と合意、日次の事前集計、正確なデータ収集の整備が効き、結果としてチームに驚きと実用性をもたらした。

VSCode上でClaude Codeのセッション状況を一枚で把握するダッシュボードを、コードを読まずに「動きを見て直す」やり方で作ったところ、同じ「使ったトークン」の数え方が画面ごとに食い違うなどの矛盾が見つかった。AIはそれに気づいていながら回答の途中に「対象外」として埋もれさせるなど、後回し・見ていないのに言い切る・言葉の意味ずれの三つの型で問題が残りやすいと分かった。

指示文にルールを足すと将来の書き方は改善するが、既存の実装の見直しは促せない。個人用途なら割り切れるが、製品レベルでは、共有指標の計算を一元化し、除外項目の記録を確認し、リファクタ後の検証方法を見直すなど、人がコードを読んで判断する工程は、やっぱり要る。

Claude Codeに触発されて「ソフトウェアファクトリー」の設計思想と、自作の運用例を解説した記事。

• 定義：チケット/PR/スケジュールを入力に、無人でマージ済みコードを生産する仕組み。実行は使い捨てマシンで完結し、状態はGitやチケット側に残す。
• 構成：タスク/実行と、チケット管理・Git・オーケストレーター・ランナー等のサービスを組み合わせる。
• 役割分担：人はチケット作成とレビュー。ランナーにClaude Codeなどを使い、部品は自分で選んで組む。
• 原則：サービスは既製品を使い、タスク（工程）は自作して差別化する。
• 事例：GitHub中心に、チャット起点→デザインPR→モック実装PR→CI→公開。2箇所で人が承認。
• 信頼性：CIの自動チェックと人のレビューという「ブレーキ」を入れ、少しずつ自動化を拡大。
• 成長：課題ごとに工程を追加（自動レビュー、失敗修復、夜間の設計整理）、スキルを振り返りで更新、共通部品を増やして適用範囲を広げる。

画像ではなく言語モデルに筆圧や運筆の指示列を出させ、筆運びという過程そのものを言語モデルでシミュレーションして「書」を生成・鑑賞できるのが「AI書道コンクール」。
「楷書の部」と「絵文字の部」があり、課題語（例：やきいも／シンギュラリティ、🐈／🍣 など）に対する各モデルの書を一覧・比較でき、表示順のソートも可能。
モデル別ページで全課題の作品を確認でき、かなや絵文字の巧さ、漢字の苦手さなど特徴の違いも見て楽しめる。