🤔 「AIがコードを書けるようになったら、ソフトウェア設計なんてもう要らないのでは?」多くの人がそう感じ始めています。この記事は、その直感がまったく逆だと教えてくれます。 コーディングは、要件理解・設計・コーディング・検証・サポートという5つの活動のうちの1つに過ぎません。人間の開発者は、設計書が多少あいまいでもチームの暗黙知や経験で補えます。しかしAIコーディングエージェント（AI-SDE）にはそれができません。設計情報が明示的に存在しなければ、既存のコードを再利用すべき場面で気づかず重複コードを生成してしまい、成熟したシステムを修正するたびに複雑さが積み重なっていきます。 さらに興味深いのは、設計の「経済学」自体が変わるという指摘です。これまでのオブジェクト指向やクラス階層は「人間が書くコード量を減らす」ためのものでした。AIによる実装コストがほぼゼロに近づく時代には、複雑な再利用構造を組むより、AIに振る舞いをシンプルに説明できる設計の方が価値を持つようになります。問いは「どう書く量を減らすか」から「AIが実装する前提で、何が最良の設計か」へと変わっていくのです。 Software Design in the Age of AI: Why AI coding makes software design more important AIが速く安くコードを書けるようになるほど、それを支える設計の質こそが問われる時代になりそうです。 #ソフトウェア設計# #AIエージェント#

今週のメルマガ：Vibe Crafting Vibe Coding——AIにコードを書かせる開発スタイル——は、まだ序の口です。本丸はその先にあります。 私がここ2か月、MulmoClaudeの開発に没頭する中でようやくハッキリ見えてきたのは、「たった一人のユーザーのために、その場で作られるソフトウェア」が当たり前になる世界です。 メルマガの読者数推移をグラフにしたい、観た映画を評価付きで記録したい、子供の習い事の送迎を管理したい——やりたいことを伝えるだけで、その目的だけのために存在する「手作りアプリ」が召喚される。コードを書く必要も、見る必要すらありません。 Karpathyの Vibe Coding がコードをAIに任せることなら、その先にあるこれを、私は「Vibe Crafting」と呼びたいと思っています。自然言語を理解するAIを前提に、ゼロから設計し直されたマン・マシン・インターフェイス。AIネイティブなコンピューティングのあるべき姿です。 一度この場所に立つと、「こうなるのが当たり前だ」としか思えなくなる。その感覚こそが、私にとって未来を見つけた時のサインです。 MulmoClaudeはオープンソースなので、よかったらご自身のPCで動かしてみてください。

🔄Loop Engineeringとはなにか？ もう「AIにプロンプトを打つ」作業は終わりにしませんか？これからは、エージェントを自律的に回す仕組みそのものを設計する時代です。AIコーディングのパラダイムシフトの正体に迫ります。 💡 1. プロンプトからシステム設計への転換 従来のAIコーディング（AI-assisted Coding）は、人間がループの「中心」にいました。 👨‍💻 これまでのアプローチ: 人間がコンテキストを考え、プロンプトを打ち、AIの出力を読み、手元でテストを実行し、エラーが出たら再度プロンプトを打つ。AIは「高機能な関数」や「道具」であり、制御の主体は常に人間です。 🔄 ループエンジニアリング: 人間はループの「外側」に出て、システム全体のデザイナー（作者）になります。仕事の検知、AIへのコンテキスト注入、出力の自動テスト、進捗の記録、次のステップの判断という一連のライフサイクルを小さなプログラムに実行させます。 ここで重要なのは、AIモデルがシステムにおける「サブルーチン（部品）」へと降格し、代わりに環境（テストスイートやリポジトリの状態）からのフィードバックをループ処理する構造へ進化したという点です。 ⚙️ 2. ループを駆動する5つのコアコンポーネント＋1つの記憶 抽象的な概念を動くシステムに落とし込むため、ループは以下のコンポーネントに分解されて設計されます。 ① ⚡ 自動化（Automations） ループの心臓部であり、発火トリガーと停止条件を定義します。 ツール（Claude CodeやCodexなど）では、単に定期実行する /loop だけでなく、明確な終了条件（例：「すべてのテストがパスするまで」）を満たすまでAIを回し続ける /goal コマンドなどがこれに該当します。条件が達成されるか、ハードストップ（予算や上限回数）に達するまで回り続けます。 ② 🌳 ワークツリー（Worktrees） 複数のAIエージェントが並列で動く場合、同じディレクトリで作業するとファイルの衝突（コンフリクト）が発生します。これを防ぐため、Gitの worktree 機能を使い、エージェントごとに独立した作業ディレクトリとブランチを隔離して自動生成します。機械的な衝突を回避し、並列性を担保する基盤です。 ③ 🧠 スキル（Skills） リポジトリのルールやコンテキストをカプセル化したものです。 通常、AIは実行ごとに前回の文脈を忘れますが、SKILL.md のようなファイルに「このプロジェクトのビルド手順」「命名規則」「過去の障害から得た注意点」を明文化しておくことで、AIは毎実行時にそれを読み込み、プロジェクト固有のシニアエンジニアのような振る舞いを固定化できます。 ④ 🔌 プラグイン／コネクタ（Connectors） filesystem（ローカルファイル）しか見えないAIを、本物の開発環境につなぐ架け橋です。 Model Context Protocol（MCP）などをベースに、GitHub（PR作成やIssue取得）、Linear/Jira（チケット更新）、Slack（人間への通知）、Sentry（エラーログの取得）と接続します。これにより、AIが「修正案を出す」だけでなく「Issueを読んで、コードを直し、PRを送り、Slackに報告する」というエンドツーエンドの行動が可能になります。 ⑤ 🤖 サブエージェント（Sub-agents） 役割を分担された独立したAIインスタンスです。「コードを書く役割（Maker）」と「コードを検証・レビューする役割（Checker）」を完全に分離します。 ➕ 💾 記憶：状態ファイル（State File） 地味ですが、ループの成否を分ける最も重要な要素です。STATE.md やJSONファイル、あるいは外部のチケット管理システムに「現在どのブランチが進行中で、何が完了し、次に何をすべきか」を永続化します。「エージェントは忘れるが、リポジトリは忘れない」という原則に従い、昨日の続きを今日のループが再開できるようにします。 🕰️ 3. なぜ「ただのcron（定期実行）」ではないのか？ 懐疑派から「1975年に発明されたcronジョブのリブランド（名前の付け替え）に過ぎないのではないか」という指摘があります。これは半分正解で、半分は間違いです。 スケジュールやトリガーのレイヤーは確かにcronそのものです。しかし、従来のcronは「固定されたスクリプトを機械的に実行するだけ」でした。 ループエンジニアリングが異なるのは、ループの真ん中に「状況を動的に判断する意思決定者（LLM）」がいる点です。 テストが落ちたとき、どのファイルをどう修正すべきか、コンテキストをどう組み立て直すかという分岐は、ハードコードされた if/else ではなく、AIの推論によって動的に決定されます。工学的な面白さは、この「崖から落ちるかもしれない不確実な意思決定者」の周りを、いかに硬牢な自動テストやガードレールで固めるかというシステムデザインにあります。 ⚠️ 4. コストと運用リスクの現実 熱狂的な議論で無視されがちなのが、経済性とセキュリティの現実です。 💸 膨大なトークン消費（コスト） コード生成自体は安価になりましたが、ループを回すと「コンテキストの再読み込み」「リトライの繰り返し」「探索パターンの実行」により、トークン消費量が爆発的に増加します。 実際に、米Uberではエンジニア1人あたり月1,500ドルの上限を設けたにもかかわらず、年間のAI予算をわずか4ヶ月で使い切った事例があります。「最大反復回数」「金額上限」「進捗ゼロ検知による強制終了」の3つのガードレール（ハードストップ）の設計が不可欠です。 🛡️ 攻撃面の拡大（セキュリティ） 無人で動くループは、無人で動く攻撃面（アタックサフェース）になります。AIコーディングツールに起因するCVE（脆弱性）が多数確認されており、コマンドインジェクションやSSRF、XSSのリスクがあります。また、外部から取り込んだ「スキル」の説明文がプロンプトインジェクションの経路になり、デバッグログ経由で認証情報（資格情報）が漏洩するケースも監査で報告されています。 🧩 理解の負債（Comprehension Debt） AIが高速でコードを書き、テストが通ってマージされ続けると、リポジトリ内のコードベースと「人間の理解度」の距離がどんどん離れていきます。これを「理解の負債」と呼びます。最も高くつくのはトークンの請求書ではなく、「チームの誰も読んだことがなく、構造を理解していないシステム」をある日突然人間がデバッグしなければならなくなるコストです。 🛠️ 5. 実践：4条件テストと最小実用ループ（MVL）の構築 ループエンジニアリングを実務に導入する際は、厳格な仕分けとステップが必要です。 📋 導入のための4条件テスト 1. タスクが繰り返されるか？（週1回未満なら、手動プロンプトや使い捨てスクリプトの方が早い） 2. 検証が完全に自動化されているか？（テスト、型チェック、Linter、ビルドが悪い出力を100%機械的に弾けるか。これがないと人間がレビューの椅子に縛り付けられる） 3. トークン予算が無駄を吸収できるか？（従量課金で予算に余裕がない場合は無謀） 4. エージェントが環境を操作する道具を持っているか？（ログ確認や再現環境など） 🚀 最小実用ループ（MVL）から始める手順 最初から複雑なマルチエージェントを組むとシステムは確実に崩壊します。以下の順番でボトムアップに構築します。 1. 手動実行の確実化: 1回の手動プロンプトと環境操作で、タスクが完全に完了することを確認する。 2. スキルの文書化: その際のコンテキストや制約を SKILL.md にまとめる。 3. ループのラップとゲート配置: AIが書いたものを自動テスト（ゲート）にかけ、失敗したらAIに戻すという1サイクルを組む。 4. スケジューリング: 最後にそれをcronやイベントトリガーで自動化する。 🎯 レバレッジの支点は「コードを書くこと」から「コードを書く仕組みを定義し、検証すること」へ移動しました。人間は、AIが自分の宿題を甘く採点しないよう、冷徹な「検証ゲート」を設計するエンジニアであり続ける必要があります。

TL;DR: 同じ Claude Opus でも、ハーネスなしは20分で$9の失敗、ハーネスありは6時間で$200のプロダクト。この差を体系的に教えるオープンソースカリキュラムです。 learn-harness-engineering 「モデルは賢い。ハーネスが信頼性を作る」——このリポジトリはAIコーディングエージェント向けのハーネス工学を14レクチャー・8プロジェクトで学ぶ教材です（⭐️ 13.7k）。 ポイント 🔧 5つのサブシステムがハーネスの骨格 ・Instructions: AGENTS.md など構造化ガイダンスでリポジトリを真実源に ・State: claude-progress.md とgit履歴でマルチセッション継続性を確保 ・Verification: テスト・lint・E2Eで「完了したふり」を防ぐ ・Scope: 明示的な完了基準で1フィーチャーずつ確実に進める ・Session Lifecycle: init → 実装 → 検証 → コミット → ハンドオフの構造的フロー 📚 段階的なカリキュラム設計 基礎（問題の直視・構造化）から発展（ループ自動化・グラフ設計・Human-in-the-Loop）まで段階的に構成。共有の Electron アプリを題材に、コードを通じてハーネスを習得します。 ⚡ すぐ既存プロジェクトに適用できる AGENTS.md・ の3ファイルをテンプレートからコピーするだけで即座に効果が出る設計。 🌐 最新のフロンティア設計も収録 Pi・Claude Code・Codex・DeepSeek の実際のハーネス設計の分析（2026年8月追加）、ループエンジニアリング・グラフエンジニアリング（2026年7月追加）と、現場の最新実践を継続的に反映しています。 エージェントを「プロンプトで動かす」から「ハーネスで信頼させる」へ、という発想の転換を13.7kのエンジニアが支持しています。 #CodingAgent# #AIエンジニアリング#

Vibe Coding with Markuplint ―AIと実装するアクセシブルなUI―【テクセシラボ#4#: ゆうてんさん】（アーカイブ） by 毬藻企画公式グッズショップ ( marimokikakugk ) ∞ SUZURI（スズリ） #suzuri# #SUZURIのデジコン#

🔬 「AIは科学を“発見”できるのか？」を、本物のNature論文90本で厳しく測ったら、最強エージェントでもSOTA超えは2割弱でした。 タイトル: NatureBench: Can Coding Agents Match the Published SOTA of Nature-Family Papers? URL: 📋 概要 Nature系ジャーナル由来の90タスク（6ドメイン）で、AIコーディングエージェントが既発表SOTAを再現・超越できるかを検証。元手法を遮断する「情報ファイアウォール」と、タスクごとにコンテナ化する自動環境NatureGymで、統一条件・Web検索禁止の厳密評価を実現しています。 🎯 解決する課題 これまでのエージェント研究ベンチは環境がバラバラで信頼性に欠けていました。本研究は「再現」ではなく「自力発見」を強制し、横断比較できる土俵を整えます。 📐 方法論 SOTA正規化の相対ギャップで採点（g>0.1で超越、g≥0で同等以上）。81種の指標を横断比較し、4時間予算・GPU割当・10エージェントを3ハーネスで評価します。 📊 実験結果 ・最強のClaude Opus 4.7でもSOTA超えは17.8%、同等以上は47.8% ・成功の45.5%は「科学課題を教師あり予測に翻訳しただけ」。真のドメイン推論はわずか8.3% ・失敗の主因は手法選択ミス45.1%と計算資源不足24.4%で、タスク誤解はわずか3.1% ・学際課題ほど成績が落ちる傾向 現状のエージェントは「翻訳」は得意でも「発見」は苦手、という冷静な現在地が見えて示唆に富みます。 #AI4Science# #CodingAgents#

🌟 AIと一緒に、自分のアイデアを形にする1日。 8月24日（月）、「子どもAI起業塾」を開催します。 小学4～6年生が、AIを「相棒（あいぼう）」にして、やってみたいことを形にする1日。今回は新しく「Vibe Coding」にも挑戦します。プログラミング言語は一切使わず、自然な言葉だけでアプリを組み上げていきます。 この講座は、完成された教材を一方的に伝える場ではありません。 子どもたちの発想やアイデアをもとに、私たちも一緒に形にしていくつもりです。 「こんなロボットがあったらいいな」 「学校にこんなものがあったらいいな」 そんな小さな「ひらめき」から、自分の手で動くものをつくる体験へ。 ▶保護者の方へ この講座は、完成された教育プログラムではありません。 子どもたちの反応を見ながら、 一緒につくっていく「実験型プログラム」です。 だからこそ、 「子どもがどんな反応をするか」「どんな表情になるか」 それ自体が、価値のある1日にと考えます。 子どもたちの可能性を探る実験にご協力頃ければ嬉しいです。 ✅ 対象：小学4～6年生（板橋区外も参加可） ✅ 日時：2026年8月24日（月） 10:00～16:00 ✅ 定員：20名（先着順） ✅ 参加費：1,000円（実験価格） ▶ お申し込み・詳細はこちら ※板橋区のお子様向けの講座ですが、区内在住・在勤でなくても大丈夫です。区外からのご参加も歓迎します。 ※小学生のお子さんがいるお知り合い、お友達にシェア、共有頃ければ幸いです。 #子どもAI起業塾# #いたばし# #AI教育#

🌟 AIと一緒に、自分のアイデアを形にする1日。 8月24日（月）、「子どもAI起業塾」を開催します。 小学4～6年生が、AIを「相棒（あいぼう）」にして、やってみたいことを形にする1日。今回は新しく「Vibe Coding」にも挑戦します。プログラミング言語は一切使わず、自然な言葉だけでアプリを組み上げていきます。 この講座は、完成された教材を一方的に伝える場ではありません。 子どもたちの発想やアイデアをもとに、私たちも一緒に形にしていくつもりです。 「こんなロボットがあったらいいな」 「学校にこんなものがあったらいいな」 そんな小さな「ひらめき」から、自分の手で動くものをつくる体験へ。 ▶保護者の方へ この講座は、完成された教育プログラムではありません。 子どもたちの反応を見ながら、 一緒につくっていく「実験型プログラム」です。 だからこそ、 「子どもがどんな反応をするか」「どんな表情になるか」 それ自体が、価値のある1日にと考えます。 子どもたちの可能性を探る実験にご協力頃ければ嬉しいです。 ✅ 対象：小学4～6年生（板橋区外も参加可） ✅ 日時：2026年8月24日（月） 10:00～16:00 ✅ 定員：20名（先着順） ✅ 参加費：1,000円（実験価格） ▶ お申し込み・詳細はこちら ※板橋区のお子様向けの講座ですが、区内在住・在勤でなくても大丈夫です。区外からのご参加も歓迎します。 ※小学生のお子さんがいるお知り合い、お友達にシェア、共有頃ければ幸いです。 #子どもAI起業塾# #いたばし# #AI教育#