AI/LLM

AI コーディングエージェントで「ランディングページを作って」くらいなら動く。しかし、複数ファイル・複数サブシステムが絡む本格的なプロジェクトになると、エージェントはコヒーレンスを失い、前に作ったものを忘れ、壊れたコードを量産し始める。GSD はこの問題を構造的に解決するシステムだ。 GSD とは GSD（Get Stuff Done）は、大規模・マルチセッションのプロジェクトを AI コーディングエージェントで完遂するためのシステムだ。デモ向けのおもちゃではなく、多数のファイルと複数のサブシステムが連携する実務レベルのプロジェクトを対象としている。 GSD が解決する問題は明確だ： エージェントは時間とともにコヒーレンスを失う 3タスク前に作ったものを忘れる ファイルは存在するが実際には動かないコードを生成する 毎ターン、プロジェクト構造の再読み込みにトークンを浪費する 中断後の再開には人間が全てを再説明する必要がある 何かが壊れたとき、クリーンなロールバック手段がない 3層の階層構造：Milestone → Slice → Task GSD はすべてのスコープを3つのレベルに分解する。 Milestone（マイルストーン） 出荷可能なバージョン。プロジェクトの大きな単位。 Slice（スライス） 独立してデモ可能な垂直的な機能単位。「データベース層を実装する」（水平的）ではなく、「ユーザーがサインアップしてログインできる」（垂直的）という形で切る。 各スライスにはデモ文がある：「これが完了すると、ユーザーは _____ できる」。この空白を人間が観察可能な行動で埋められなければ、スコープの切り方が間違っている。 Task（タスク） コンテキストウィンドウ1つ分の作業単位。1タスクが1エージェントセッションに収まらなければ、それは2タスクだ。これは鉄則であり、違反するとエージェントがコヒーレンスを失い始める — 長時間の作業で初期の判断がコンパクション（圧縮）され、コンテキストが古いツールコールで汚染され、推論品質が劣化する。 Boundary Maps — 実装前のインターフェース思考 GSD で最もインパクトのある計画機能がこれだ。 マイルストーンの計画時に、各スライスは何を生産し、上流のスライスから何を消費するかを具体的に宣言する。曖昧にではなく、関数名・型名・インターフェース・エンドポイントを名前付きで。 S01 → S02 Produces: types.ts → User, Session, AuthToken (interfaces) auth.ts → generateToken(), verifyToken(), refreshToken() Consumes: nothing (leaf node) S02 → S03 Produces: api/auth/login.ts → POST handler middleware.ts → authMiddleware() Consumes from S01: auth.ts → generateToken(), verifyToken() これにより「スライス3が必要とする関数をスライス1がエクスポートしていない」という問題が発生しない。契約が明示的で、検証可能になる。 ...

Claude Code や Codex といった AI コーディングエージェントを現場に投入する開発者が増えるなか、「ハーネスエンジニアリング」という新しい実践領域が注目を集めている。逆瀬川氏（@gyakuse）が公開したまとめ記事から、要点を紹介する。 そもそも「ハーネス」とは何か 「ハーネス（harness）」とは、もともと馬具の意味だ。馬の力を人間が制御して活かすための装具一式 — 手綱、鞍、轡（くつわ）などを指す。馬がどれだけ優秀でも、ハーネスなしでは暴走するだけで仕事にならない。 ソフトウェアの世界では「テストハーネス」という用語がすでにある。テスト対象のコードを「つなぎ止めて」、入力を与え、出力を検証する枠組みのことだ。テスト対象そのものではなく、テスト対象を正しく動かすための外側の仕組みを指す。 AI コーディングエージェントにおける「ハーネス」もこれと同じ発想だ。AI エージェント（= 馬）は強力だが、そのままでは暴走する。古いドキュメントを信じてしまう、リンターのルールを勝手に緩和する、前のセッションで何をしたか忘れる。エージェントを制御し、安定した成果を引き出すための外側の仕組み全体がハーネスであり、それを設計・構築する技術がハーネスエンジニアリングだ。 具体的にハーネスを構成する要素は、大きく 3 つの層に分けられる: 入力層 — エージェントに何を読ませ、何を読ませないかを制御する（AGENTS.md の設計、リポジトリの衛生管理、セッション間の状態引き継ぎ） 実行制御層 — エージェントの作業中にリアルタイムで品質を強制する（リンター・フォーマッターの自動実行、計画と実行の分離） 検証層 — エージェントの出力が正しいことを確認する（E2E テスト、プリコミットチェック） 核心的な洞察は「ハーネスがモデルより重要」という点だ。同じモデルでもハーネスを改善すれば出力品質が劇的に向上する。開発者の責任は「正しいコードを書く」から「エージェントが確実に正しいコードを生産する環境を設計する」へとシフトしている。 7 つの主要トピック 1. リポジトリ衛生 〈入力層〉 「衛生（hygiene）」は、ソフトウェア開発で「不要物や汚染を取り除き、健全な状態を保つ」という意味で使われる慣用表現だ（「コードハイジーン」「ブランチハイジーン」なども同様）。ここでは、リポジトリ内に古くなったドキュメントや不正確な情報が溜まらないよう清潔に保つことを指す。人間なら「このメモ、古そうだな」と判断できるが、エージェントは 3 ヶ月前のメモも最新のコードも同じ「事実」として読んでしまう。だから情報の鮮度管理が重要になる。 実行可能なアーティファクト（コード、テスト、設定）を優先する 説明的ドキュメントは腐敗しやすいため最小化する ADR（Architecture Decision Records）で決定履歴を保全する テストはドキュメントより腐敗に強い 最大の敵は「説明的ドキュメントの腐敗」だ。エージェントは「3 ヶ月前のメモ」と「現在の真実」を区別できないため、古い情報が存在するだけで性能が低下する。ハーネスの入力層として、エージェントが読む情報の鮮度と正確性を保つことが最初のステップになる。 2. 決定論的ツールで品質を強制する 〈実行制御層〉 「決定論的（deterministic）」とは、同じ入力に対して毎回必ず同じ結果を返すという意味だ。リンターやフォーマッターがその典型で、たとえば「未使用の変数がある」というコードを渡せば、何度実行しても必ず同じ警告を返す。気分や文脈によって判断が揺れることがない。 対照的に、LLM は非決定論的だ。同じコードを渡しても、実行するたびにチェックの粒度や指摘内容がブレる。「インデントを揃えて」と指示しても、ある時はスペース 2 つ、別の時はタブで揃えるかもしれない。 だからこそ、機械的に判定できるルール（構文エラー、未使用変数、フォーマット）は LLM に任せず、決定論的ツールに委ねるのが原則だ。PostToolUse Hook でファイル編集のたびにリンターを自動実行し、エラーをエージェントに即時フィードバックする。 言語別の推奨スタック: 言語 PostToolUse プリコミット カスタムルール TypeScript Biome + Oxlint tsc + ESLint eslint-plugin-local-rules Python Ruff check/format Ruff + mypy ast-grep Go gofumpt + golangci-lint 同左 ast-grep リンター設定の保護も重要だ。エージェントがルールを勝手に緩和・改ざんするのを防ぐ仕組みが必要になる。これはまさに「手綱」の役割 — エージェントが暴走しないよう、作業のたびに自動で引き戻す仕組みだ。 ...

Claude Code や Codex といった AI コーディングエージェントを現場に投入する開発者が増えるなか、「ハーネスエンジニアリング」という新しい実践領域が注目を集めている。逆瀬川氏（@gyakuse）が公開したまとめ記事（読了 54 分）から、要点を紹介する。 そもそも「ハーネス」とは何か 「ハーネス（harness）」とは、もともと馬具の意味だ。馬の力を人間が制御して活かすための装具一式 — 手綱、鞍、轡（くつわ）などを指す。馬がどれだけ優秀でも、ハーネスなしでは暴走するだけで仕事にならない。 ソフトウェアの世界では「テストハーネス」という用語がすでにある。テスト対象のコードを「つなぎ止めて」、入力を与え、出力を検証する枠組みのことだ。テスト対象そのものではなく、テスト対象を正しく動かすための外側の仕組みを指す。 AI コーディングエージェントにおける「ハーネス」もこれと同じ発想だ。AI エージェント（= 馬）は強力だが、そのままでは暴走する。古いドキュメントを信じてしまう、リンターのルールを勝手に緩和する、前のセッションで何をしたか忘れる。エージェントを制御し、安定した成果を引き出すための外側の仕組み全体がハーネスであり、それを設計・構築する技術がハーネスエンジニアリングだ。 具体的にハーネスを構成する要素は、大きく 3 つの層に分けられる: 入力層 — エージェントに何を読ませ、何を読ませないかを制御する（AGENTS.md の設計、リポジトリの衛生管理、セッション間の状態引き継ぎ） 実行制御層 — エージェントの作業中にリアルタイムで品質を強制する（リンター・フォーマッターの自動実行、計画と実行の分離） 検証層 — エージェントの出力が正しいことを確認する（E2E テスト、プリコミットチェック） 核心的な洞察は「ハーネスがモデルより重要」という点だ。Morph の分析によると、同じモデルでもハーネスを変えると SWE-bench スコアが 22 ポイント変動するのに対し、モデルの交換では 1 ポイントしか変わらない。開発者の責任は「正しいコードを書く」から「エージェントが確実に正しいコードを生産する環境を設計する」へとシフトしている。 7 つの主要トピック 1. リポジトリ衛生 〈入力層〉 「衛生（hygiene）」は、ソフトウェア開発で「不要物や汚染を取り除き、健全な状態を保つ」という意味で使われる慣用表現だ（「コードハイジーン」「ブランチハイジーン」なども同様）。ここでは、リポジトリ内に古くなったドキュメントや不正確な情報が溜まらないよう清潔に保つことを指す。人間なら「このメモ、古そうだな」と判断できるが、エージェントは 3 ヶ月前のメモも最新のコードも同じ「事実」として読んでしまう。だから情報の鮮度管理が重要になる。 実行可能なアーティファクト（コード、テスト、設定）を優先する 説明的ドキュメントは腐敗しやすいため最小化する ADR（Architecture Decision Records）で決定履歴を保全する テストはドキュメントより腐敗に強い 最大の敵は「説明的ドキュメントの腐敗」だ。エージェントは「3 ヶ月前のメモ」と「現在の真実」を区別できないため、古い情報が存在するだけで性能が低下する。ハーネスの入力層として、エージェントが読む情報の鮮度と正確性を保つことが最初のステップになる。 2. 決定論的ツールで品質を強制する 〈実行制御層〉 「決定論的（deterministic）」とは、同じ入力に対して毎回必ず同じ結果を返すという意味だ。リンターやフォーマッターがその典型で、たとえば「未使用の変数がある」というコードを渡せば、何度実行しても必ず同じ警告を返す。気分や文脈によって判断が揺れることがない。 対照的に、LLM は非決定論的だ。同じコードを渡しても、実行するたびにチェックの粒度や指摘内容がブレる。「インデントを揃えて」と指示しても、ある時はスペース 2 つ、別の時はタブで揃えるかもしれない。 だからこそ、機械的に判定できるルール（構文エラー、未使用変数、フォーマット）は LLM に任せず、決定論的ツールに委ねるのが原則だ。 ここで重要なのが「ほぼ毎回」と「例外なく毎回」の差だ。CLAUDE.md に「リンターを実行せよ」と書くだけでは前者にとどまる。コンテキストウィンドウの消費が進むと、エージェントはリンターの存在を忘れてしまうからだ。Claude Code の Hook（特定のライフサイクルイベントで自動実行されるスクリプト）で強制すれば後者になる。 ...

AI コーディングツール（Claude Code、Cursor、Gemini CLI など）で UI を生成すると、「動くけど見た目がイマイチ」になりがちだ。Impeccable は、AI に設計のボキャブラリーを教えることで、生成される UI の品質を引き上げるスキルライブラリだ。 Impeccable とは Impeccable は、Paul Bakaus 氏が開発した AI コーディングツール向けの設計スキル拡張だ。Anthropic の公式 frontend-design スキルをベースに、17個のコマンドと厳選されたアンチパターン集を提供する。 「派手なデザイン」ではなく「洗練された仕上がり」を目指すのが特徴で、中国のインディー開発者コミュニティでも注目を集めている。 対応ツール Cursor Claude Code Gemini CLI Codex CLI VS Code Copilot Google Antigravity Kiro インストール方法 npx（推奨） 1 npx skills add pbakaus/impeccable Claude Code の場合 1 2 3 4 5 # プロジェクト単位 cp -r dist/claude-code/.claude your-project/ # グローバル cp -r dist/claude-code/.claude/* ~/.claude/ Cursor の場合 1 cp -r dist/cursor/.cursor your-project/ Nightly チャンネルの使用と Agent Skills の有効化が必要。 ...

Andrej Karpathy が公開した autoresearch は、AI エージェントが単一 GPU 上で自律的に ML 実験を繰り返すツールです。わずか約630行の Python コードで「コード修正 → 学習 → 評価 → 改善」のループを自動化し、研究の競争軸を「コード品質」から「改善ループの速度」へと変えようとしています。 autoresearch とは autoresearch のコンセプトはシンプルです: AIエージェントに小さいが本物の LLM トレーニング環境を渡し、一晩中自律的に実験させる エージェントはトレーニングコード（train.py）を自動修正し、5分間のトレーニングを実行、検証損失（val_bpb）が改善したかを確認し、結果に基づいて次の実験に進みます。 プロジェクト構成 autoresearch はたった3つのファイルで構成されています: ファイル 役割 編集者 prepare.py データ準備・ランタイムユーティリティ 変更不可 train.py モデル・オプティマイザ・学習ループ AIエージェント program.md エージェントへの指示書 人間 従来のML研究では Python ファイルを直接編集しますが、autoresearch では Markdown ファイル（program.md）でエージェントに指示を与える という設計になっています。人間が行うのは「プログラムのプログラミング」です。 固定時間予算という設計判断 autoresearch の重要な設計判断は、全てのトレーニングを ちょうど5分間 に固定していることです: 1時間あたり約12回の実験が可能 一晩（8時間）で約100回の実験を自動実行 プラットフォームに依存せず公平な比較が可能 1 2 3 4 5 6 # セットアップ uv sync uv run prepare.py # データ準備（初回のみ、約2分） # 単一実験の実行 uv run train.py # 約5分で完了 エージェントの起動は、Claude などの AI に対して以下のように指示するだけです: ...

OpenAI が Symphony というオープンソースの自動化基盤をリリースしました。Issue トラッカーから課題を読み取り、課題ごとに隔離ワークスペースを作成し、AI エージェントに実装を走らせるオーケストレーションフレームワークです。 Symphony とは Symphony は、AI コーディングエージェントを手動のプロンプト操作から構造化された自律実行へと移行させるためのフレームワークです。Elixir / Erlang BEAM ランタイム上に構築されており、長時間実行される独立した「実装ラン（implementation run）」を高い並行性と耐障害性で管理します。 従来の「AI にコードを書かせて PR を出す」という手動プロンプト型のワークフローを、カンバンボードのタスクカードを移動するだけで管理できるようにします。 動作の仕組み Symphony の基本的な流れは以下の通りです: 課題の読み取り — Issue トラッカー（現在は Linear をサポート）からタスクを継続的に監視 隔離ワークスペースの作成 — 各課題に対して独立したワークスペースを生成 エージェントの実行 — ワークスペース内でコーディングエージェントセッションを実行 成果物の提出 — CI ステータス、PR レビューフィードバック、複雑度分析、操作動画などの「作業証明」を提供 承認とマージ — タスクが承認されると、エージェントが安全に PR をマージ 技術的な特徴 WORKFLOW.md によるエージェント制御 エージェントのプロンプトやランタイム設定は、リポジトリ内の WORKFLOW.md に直接保存されます。これにより、AI の動作指示がコードとしてバージョン管理され、変更対象のブランチと同期されます。 Elixir / BEAM ランタイムの採用 Elixir と Erlang/BEAM ランタイムを採用することで、以下のメリットがあります: 高い並行性 — 複数のエージェントセッションを同時に管理 耐障害性 — 個別の実装ランが失敗してもシステム全体に影響しない 長時間実行への対応 — エージェントの長時間稼働を安定的にサポート Poll-Dispatch-Resolve-Land ワークフロー Symphony の中核となるワークフローパターンです: ...

18歳、コーディング経験ゼロ、高校を卒業したばかりの起業家が OpenClaw を使って15人の AI エージェントチームを構築し、月額400ドルで24時間稼働させている事例が話題になっています。GitHubやIDEの知識がなくても、AI チームを組織できる時代が来ています。 OpenClaw とは OpenClaw は、Peter Steinberger が開発したオープンソースの自律型 AI エージェントです。2026年3月時点で GitHub スター数は約247,000、フォーク数は47,700を超え、爆発的な成長を遂げています。 完全にオープンソースでサブスクリプションや API 費用が不要なため、実際にかかるコストはハードウェアと電気代のみ。専用サーバー（OVH で月45ドル、Hetzner で月40ドル程度）を使えば、低コストで本格的な AI チームを運用できます。 AI チームの構成 YouTube 動画「I Built a Full AI Team Inside OpenClaw for $400/Month」（4.2万回再生）では、以下のような AI エージェントチームの構築が紹介されています: エージェント名 役割 ATLAS 戦略・計画策定 SCRIBE ドキュメント・コンテンツ作成 PIXEL デザイン・ビジュアル NOVA リサーチ・分析 SENTINEL 監視・品質管理 CLOSER セールス・クロージング CLAND コーディング・開発 CLIP 動画・メディア編集 各エージェントは agents/ フォルダ内にサブフォルダとして定義され、それぞれの AGENTS.md に役割・ツール・振る舞いが記述されます。 セットアップの仕組み OpenClaw のマルチエージェント構成は以下のような構造です: workspace/ ├── agents/ │ ├── atlas/ │ │ └── AGENTS.md # 戦略担当の定義 │ ├── scribe/ │ │ └── AGENTS.md # ライティング担当の定義 │ ├── cland/ │ │ └── AGENTS.md # 開発担当の定義 │ └── ... └── program.md # チーム全体への指示 エージェントは MCP スキルを通じて各種ツールと連携し、Reddit や Twitter のシグナル収集、トレンド分析、コンテンツ生成などを自律的に実行します。 ...

2025年末に「Clawdbot」として登場し、2026年に入ってから GitHub スター数20万超を記録した OpenClaw が大きな話題になっています。この記事では、OpenClaw の概要、主要機能、セキュリティ上の注意点、そしてセットアップ方法までを解説します。 OpenClaw とは OpenClaw は、Peter Steinberger 氏が開発したオープンソースの AI エージェントフレームワークです。従来のチャットボットが「テキストを生成する」だけだったのに対し、OpenClaw は 実際にタスクを実行する 点が最大の特徴です。 公式サイトのキャッチフレーズは “The AI That Actually Does Things” 。ファイル操作、シェルコマンドの実行、Web ブラウジング、フォーム入力など、PC 上のさまざまな操作を AI に任せることができます。 主要機能 チャットプラットフォーム統合 WhatsApp、Telegram、Discord、Slack、Signal、iMessage など、普段使っているメッセージアプリから自然言語で指示を出せます。専用アプリや Web サイトを開く必要はありません。 実行可能なタスク メール管理: 未読メールの自動分析・優先順位付け、定型返信の作成 スケジュール調整: カレンダー確認、飲食店予約の自動実施 開発支援: GitHub コード履歴の確認、プルリクエストレビュー ブラウザ制御: Web サイト閲覧、フォーム入力、データ抽出の自動化 ローカルファースト設計 個人デバイスやローカルサーバーで動作し、Raspberry Pi のような低価格デバイスでも実行可能です。クラウド利用時も暗号化環境を採用しています。 永続的メモリ ユーザーの好みやコンテキストを記憶し、使い込むほど賢くなる仕組みが組み込まれています。 セットアップ方法 Node.js 22 以上が必要です。 1 npm install -g openclaw@latest インストール後、オンボーディングウィザードで API 設定を完了します。LLM バックエンドは Claude、GPT、Ollama 経由のローカルモデルに対応しており、自分の API キーを使う方式（BYOK）です。 ...

AIエージェントに役職・組織図・予算・目標を与え、24時間自律的に会社を運営させる——そんなコンセプトのオープンソースプロジェクト「Paperclip」が公開され、注目を集めている。 Paperclip とは Paperclip は、複数の AI エージェントを「社員」として組織化し、会社として機能させるためのオーケストレーションプラットフォームだ。 “If OpenClaw is an employee, Paperclip is the company.” 個々の AI エージェントを個別に管理するのではなく、組織図・予算・ガバナンス・目標整合・タスク調整といった会社レベルのインフラを提供する。 GitHub: https://github.com/paperclipai/paperclip 公式サイト: https://paperclip.ing/ ライセンス: MIT 主な機能 エージェントの組織化 組織図（Org Chart）: 階層構造、役職、レポートラインを定義 目標整合（Goal Alignment）: 会社のミッションからプロジェクト目標、個別タスクまで文脈が伝播 マルチカンパニー対応: 1つのデプロイで複数の会社を完全分離して管理 対応エージェント Claude、OpenClaw、Codex、Cursor、Bash スクリプト、HTTP Webhook など、ハートビートシグナルを受信できる任意のランタイムと連携できる。 コスト管理 エージェントごとに月次予算を設定し、使用量80%で警告、100%で自動停止する。暴走的なトークン消費を防ぐ仕組みが組み込まれている。 ガバナンスと監査 人間による承認ゲート（採用・戦略変更時） 設定変更のバージョニングとロールバック 全ての会話・意思決定・ツール呼び出しの追跡ログ いつでもエージェントの一時停止・再割り当て・終了が可能 セットアップ 1 2 3 4 5 6 7 8 # クイックスタート npx paperclipai onboard --yes # 手動インストール git clone https://github.com/paperclipai/paperclip.git cd paperclip pnpm install pnpm dev API は http://localhost:3100 で起動し、組み込みの PostgreSQL データベースを使用する。要件は Node.js 20+ と pnpm 9.15+。 ...

Alibaba Cloud の Qwen チームが 2026 年 2 月にリリースした Qwen3.5-27B は、27B パラメータという中規模サイズながら上位モデルに匹敵する性能を発揮する密（dense）モデルです。メモリ効率に優れ、量子化を活用すれば個人の PC でも快適に動作するため「自分専用 AI」を構築するのに最適な選択肢として注目されています。 Qwen3.5-27B の主な特徴 アーキテクチャ Qwen3.5-27B は MoE（Mixture of Experts）ではなく、全パラメータが推論時に活性化される 密モデル（dense model） です。Gated Delta Networks と Feed Forward Networks を組み合わせた構造で、高い計算密度を実現しています。 パラメータ数: 27B（全パラメータ活性化） コンテキスト長: 262K トークン（最大 1M まで拡張可能） 対応言語: 201 言語 マルチモーダル: 視覚・言語の統合能力を搭載 ベンチマーク性能 27B というサイズにもかかわらず、主要ベンチマークで際立った成績を残しています。 ベンチマーク スコア MMLU-Pro 86.1% GPQA Diamond 85.5% SWE-bench Verified 72.4% LiveCodeBench 80.7% IFEval 95.0% HMMT（数学） 92.0% 特に SWE-bench Verified で 72.4% は GPT-5 mini と同等の数値であり、オープンウェイトの 27B 密モデルとしては驚異的な結果です。コーディング、数学、指示追従の各タスクで中規模モデルカテゴリをリードしています。 ...