記事一覧

AIエージェントを使った「0人会社（zero-human company）」のコンセプトが現実に近づいている。 Paperclip は、そのためのオーケストレーション基盤としてオープンソース化されたツールだ。 Paperclip とは Paperclip は「ゼロヒューマン企業」を動かすためのオーケストレーション層（orchestration layer）。 人間なしで自律的に業務が進む組織を設計・運用するための基盤として設計されている。 GitHubリポジトリ: paperclipai/paperclip リリース後またたく間にスターが集まり、2026年3月時点で 53,000スター超 を記録している。 主な機能 Paperclip が提供する機能は次の通り: 組織図（Org Charts） — エージェントの役割と階層を定義する 目標整合（Goal Alignment） — 組織全体の目標を各エージェントのタスクに紐付ける タスクの責任者（Task Ownership） — どのエージェントが何を担うかを明確に割り当てる 予算管理（Budgets） — エージェントが使用できるリソースや費用に上限を設定する エージェントテンプレート（Agent Templates） — 役割ごとの標準的なエージェント設定を再利用する これらの仕組みにより、人間のオペレーターが常時介在しなくても「自律的に仕事が進む会社」を実現できる。 クイックスタート セットアップは npx で1コマンド: 1 npx paperclipai onboard このコマンドを実行すると、初期の組織設計のガイドが始まる。TypeScript 製で、Node.js 環境があればすぐに試せる。 なぜ注目されるのか 従来の AI エージェントフレームワークの多くは、単一エージェントまたは単純なマルチエージェントの連携を想定している。Paperclip が異なるのは、企業・組織レベルの構造をファーストクラスの概念として扱っている点だ。 単なるタスクキューではなく、組織図と権限委譲を持つ エージェント同士の目標が整合されていることを保証する仕組みがある 予算制約により無限ループや暴走を防ぐ設計になっている 「AIエージェントに会社を任せる」という考えを本格的にサポートするインフラとして、エンジニアコミュニティの注目を集めている。 参考リンク paperclipai/paperclip - GitHub オープンソース化を告知したツイート（@dotta）

redis-py の Lock クラスは UUID ベースのトークンでロックの所有権を管理するが、フェンシングトークン（単調増加する数値）は提供しない。しかし、Lock クラスは do_acquire や Lua スクリプトをオーバーライドできる設計になっており、サブクラス化でフェンシングトークンを追加できる。 本記事では、redis-py の Lock を拡張してフェンシングトークンを発行する FencedLock クラスの実装例を紹介する。 前提知識：Redis の Lua スクリプティング Redis はバージョン 2.6 から Lua スクリプトの実行機能を内蔵している。EVAL コマンドで Lua スクリプトを Redis サーバー上で直接実行でき、複数の Redis コマンドをアトミック（不可分）に実行できる。 なぜ Lua スクリプトが必要か 通常、Redis コマンドは1つずつ実行される。例えば「キーが存在しなければセットし、同時にカウンターをインクリメントする」という処理を2つのコマンドで行うと、その間に他のクライアントが割り込む可能性がある： クライアント A: SET mykey value NX → 成功 ← クライアント B が割り込む余地 クライアント A: INCR counter → インクリメント Lua スクリプトを使えば、この2つの操作を1回のアトミックな呼び出しにまとめられる： 1 2 3 4 5 6 -- Redis サーバー上で実行される（他のコマンドは割り込めない） local ok = redis.call('SET', KEYS[1], ARGV[1], 'NX') if ok then return redis.call('INCR', KEYS[2]) end return nil Redis CLI での実行例 1 2 # EVAL "スクリプト" キーの数 キー1 キー2 ... 引数1 引数2 ... redis-cli EVAL "return redis.call('SET', KEYS[1], ARGV[1])" 1 mykey myvalue redis-py での実行例 1 2 3 4 5 6 7 8 9 10 import redis r = redis.Redis() # 方法1: eval で直接実行 r.eval("return redis.call('SET', KEYS[1], ARGV[1])", 1, "mykey", "myvalue") # 方法2: register_script で事前登録（推奨） # サーバー側に SHA1 でキャッシュされ、2回目以降はスクリプト本文の転送が不要 script = r.register_script("return redis.call('GET', KEYS[1])") result = script(keys=["mykey"]) セキュリティ上の注意 Lua スクリプトのパラメータは KEYS[] と ARGV[] で渡される。SQL のプリペアドステートメントと同様に、パラメータが文字列としてスクリプトに展開されることはないため、パラメータ経由でのインジェクションはできない。ただし、ユーザー入力でスクリプト文字列自体を動的に組み立てると危険なので、スクリプトは固定文字列として定義すること。 ...

takt は、Claude Code や Codex などの AI コーディングエージェントのワークフローを YAML で定義できる CLI ツールです。エージェントに単にコードを書かせるだけでなく、レビューループや人間の介入ポイントを宣言的に管理することで、品質の高いアウトプットを継続的に得られるよう設計されています。 takt とは TAKT は TAKT Agent Koordination Topology の略で、ドイツ語の「拍子・指揮棒」を由来とする名前です。オーケストラの指揮者のように複数の AI エージェントを統率するというコンセプトが込められています。 GitHub: https://github.com/nrslib/takt 言語: TypeScript スター数: 952（2026年4月時点） ライセンス: MIT 対応エージェント: Claude Code、Codex、OpenCode、Cursor、GitHub Copilot CLI なぜ takt が必要か AI コーディングエージェントを使う上で重要なのは、ワークフローの設計です。エージェントに「コードを書いて」と指示するだけでは、品質にばらつきが生じます。takt は以下の課題を解決します: レビューループの自動化: 実装 → レビュー → 修正 のサイクルを自動で回す 再現性の確保: 実行パスを YAML で宣言するため、チーム間で同じ品質プロセスを共有できる マルチエージェント対応: 異なるペルソナ・権限・レビュー基準を持つ複数エージェントをオーケストレーション 完全なトレーサビリティ: 全ステップを NDJSON でログに記録 インストールと基本的な使い方 1 npm install -g takt 設定ファイル ~/.takt/config.yaml を作成してプロバイダーを指定します: ...

「AIに言葉で指示するだけ」のバイブコーディング（vibe coding）において、どんな人が高い成果を出せるのか——CHI2026 に採択された論文の知見が注目を集めています。 バイブコーディングとは バイブコーディングとは、実際のコードを読み書きせず、AI に自然言語で指示するだけでソフトウェアを開発するスタイルです。ChatGPT や GitHub Copilot などの生成 AI の台頭により、プログラミング経験のない人でも簡単なアプリを作れるようになったことで注目されています。 しかし「コードを書かなくていいなら、誰でも同じ成果が出せる」かというと、実験結果はそう単純ではありませんでした。 CS 基礎知識がある人ほど成績が良い 論文によると、コンピュータサイエンス（CS）の基礎知識がある人ほどバイブコーディングの成績が高いという結果が得られています。 コードを一切読み書きしない状況でも、以下のような CS 的な思考が AI への指示を組み立てる上で役立つと考えられています。 問題分解の思考法: 大きな問題を小さなステップに分解する能力 アルゴリズム的な発想: 処理の流れや条件分岐を論理的に考える力 データ構造の概念: 何をどう扱うかを抽象的に把握する力 AI に指示を出す際も、「何をしてほしいか」を明確に分解して伝える必要があります。CS の素養は、そのための基盤となるわけです。 文章力が高い人ほど良い成果が出せる さらに注目すべき知見として、文章力が高い人ほどバイブコーディングの成果が高いという傾向が示されています。 その連鎖は非常に明快です。 文章力が高い → プロンプトの品質が高い → アプリの出来が良い AI に対して意図を的確に伝える「プロンプト」は、本質的には文章です。論理的で明確な指示を書ける人は、AI から意図した出力を引き出しやすく、結果として高品質なアプリを作れるということです。 意外な発見：LLM ヘビーユーザーは成績が低い傾向 今回の実験で驚きの結果も明らかになっています。LLM を普段からよく使っている人ほど、バイブコーディングの成績が低く、文章力も低い傾向があるというものです。 因果関係は断定できませんが、研究チームは 2 つの可能性を考察しています。 LLM への依存が言語化能力を低下させる: AI に頼りすぎることで、自分で言語化する力が鍛えられなくなる もともと言語化が苦手な人が LLM を多用する: 自分で考えて伝えることが苦手なため、AI に委ねる頻度が高くなる この知見は、AI ツールとの関わり方を見直すきっかけになりそうです。 まとめ CHI2026 採択論文のこの知見をまとめると、バイブコーディングで成果を出せる人の特徴は次の通りです。 要因 傾向 CS 基礎知識 あるほど成績が高い 文章力 高いほど成績が高い LLM 利用頻度 高いほど成績が低い（意外な結果） 「コードを書かなくていい時代」だからこそ、問題を論理的に分解する力 と 意図を明確に言語化する力 がより重要になる——この研究はそのことを示唆しています。 ...

きっかけ ある日、開発環境の Web アプリにアクセスしたら証明書の期限切れ警告が表示された。 確認してみると、ワイルドカード証明書 (*.dev.example.com) がちょうどその日に期限切れになっていた。さらにもう1つ古い証明書も半年前に失効済み。 Certificate Name: dev.example.com-0001 Domains: *.dev.example.com Expiry Date: 2026-03-17 (INVALID: EXPIRED) Certificate Name: dev.example.com Domains: *.dev.example.com dev.example.com Expiry Date: 2025-09-17 (INVALID: EXPIRED) 原因 certbot の renewal 設定を確認したところ、問題が見えた。 1 2 3 [renewalparams] authenticator = manual pref_challs = dns-01, authenticator が manual になっていた。 ワイルドカード証明書は DNS-01 チャレンジが必須だが、manual モードでは certbot が更新のたびに「この TXT レコードを DNS に追加してください」と対話的に聞いてくる。つまり 自動更新が不可能 な状態だった。 systemd timer (certbot.timer) は1日2回動いていたが、manual モードの証明書は自動更新をスキップされるため、期限切れまで放置されていた。 対応方針 2つの選択肢を検討した。 ...

Claude Code は「コード」という名前のせいでエンジニア向けツールだと思われがちですが、実は日本語で仕事を渡すツールです。インストール1分、コード0行——非エンジニアこそ今すぐ使い始めるべき理由と、効果を最大化する CLAUDE.md の作り方を解説します。 Claude Code はプログラミングツールではない X を見ると、デザイナーがコード1行も書かずにニュース収集→記事→サムネ→SNS投稿まで全部自動化していたり、会計士が Excel 作成・PowerPoint 操作・Gmail 連携まで全部 AI に回していたりします。 エンジニアではない人たちがガンガン使っている。それなのに「難しそう」で止まっている人は、素手で戦っているようなものです。 ChatGPT は「聞く」ツール。Claude Code は「やらせる」ツール。 Claude の強みはライティング・分析・思考・ファイル操作です。ここは今の AI の中でも頭一つ抜けています。「仕事を渡す」用途に限れば、現時点で最も実用的なツールのひとつです。 怖い人はまずブラウザ版の Claude Chat（claude.ai）だけでも十分です。文体カスタマイズ、会話記憶、Excel/PowerPoint の直接作成、Gmail 連携——ブラウザだけでかなりのことができます。そこから始めて、「もっとやらせたい」と思ったら Claude Code に進む、この順番でいいと思います。 セットアップ — 1分で終わる やることは3ステップだけです。 ステップ1: インストール ターミナル（Mac）または PowerShell（Windows）を開いて、以下のコマンドを1行貼り付けます。 Mac: 1 curl -fsSL https://claude.ai/install.sh | bash Windows: 1 irm https://claude.ai/install.ps1 | iex 約1分で完了します。 ...

Corey Ganim 氏が公開した「Ultimate Claude Cowork Starter Pack」が話題になっています。Claude Cowork を単なるチャットボットではなく、本格的な生産性ツールとして活用するための設定方法を体系的にまとめた記事です。本稿ではその要点を日本語で紹介します。 Claude Cowork とは Claude Cowork は Anthropic が提供するデスクトップ向け AI ワークスペースです。プラグイン・スキル・コンテキストファイルを組み合わせることで、日常業務を大幅に効率化できます。 まずインストールすべき4つのプラグイン 1. Productivity プラグイン（最優先） タスク管理・スケジューリング・ワークフロー自動化を提供します。 /task — タスクの作成・追跡 /schedule — カレンダーへの時間ブロック /workflow — 保存済みの多段ステップ自動化の実行 2. Marketing プラグイン コンテンツ制作を支援します。 1つのコンテンツを5つの SNS 投稿に変換 テーマとフックを含むコンテンツカレンダーの作成 キャンペーンの一括管理 3. Data プラグイン データ分析タスクに対応します。 スプレッドシートの分析 ダッシュボードの構築 データの整理・変換 4. Sales プラグイン 営業活動を効率化します。 アカウントリサーチ ミーティング前ブリーフの自動作成（通常30分 → 3分に短縮） アウトリーチ文面の生成 コンテキストファイルの設定 Ganim 氏が強調するのは「プロンプトの時代は終わり、コンテキストの時代が来た」（The prompting game is over. The context game is everything.）という点です。 ...

Claude Code の使い方として注目を集めているのが、「就寝前タスク投げ」スタイルだ。デジライズ CEO のチャエン氏（@masahirochaen）が X（旧 Twitter）に投稿した体験談が多くの反響を呼んでいる。 就寝前に大量タスクを投げ、朝には完成している世界 チャエン氏の投稿要旨はこうだ。 Claude Code の良さは、寝る前にえげつない量のタスクを振れること。 私は毎晩、検証したい事業アイデアへの指示を出してからベッドに入る。 今日は市場リサーチから要件定義、モック作成、コードレビューまで—— 人間だったら 25 人月 × 5 ヶ月はかかる業務量。 人件費換算で約 3,000 万円分らしい。 これを寝る前の 2 分の指示だけで動かして、朝起きたら完成してる世界線半端ないです。シンギュラリティ味を感じます。 この投稿は 2026 年 3 月 16 日時点で約 39 万インプレッション、2,800 件超のいいねを記録し、大きな話題となった。 Claude Code がこのワークフローを可能にする理由 Claude Code は Anthropic が提供するターミナルベースの AI コーディングエージェントだ。単なるコード補完ではなく、以下のような複合的な作業を自律的にこなせる。 市場リサーチ: Web 検索・情報収集・競合分析 要件定義: ユーザーストーリーや仕様書の作成 モック作成: UI/API のプロトタイプ生成 コードレビュー: 品質チェックと改善提案 従来これらは専門の担当者が分担して進める工程だが、Claude Code は一連の指示をもとに自律的に連鎖実行できる。「エージェント型」と呼ばれるゆえんだ。 「就寝前 2 分指示」スタイルの実践ポイント チャエン氏の使い方から読み取れる実践のコツをまとめる。 1. 具体的なゴールを宣言する 「事業アイデアを検証したい」という大きなゴールを明示することで、Claude Code が必要なサブタスクを自律的に分解・実行できる。 2. タスクを細かく区切りすぎない 「市場リサーチ → 要件定義 → モック → レビュー」という流れを一気に渡すことで、成果物間の整合性が取れた状態で仕上がる。 ...

Claude Code を活用して税理士がスタッフ 0 人で顧問先 60 社を運営している事例が話題になっている。この事例が示すのは、AI 駆動開発による IT 企業のコスト構造の崩壊と、「技術力」から「ドメイン知識」への価値シフトだ。 税理士事務所の事例：6人分の人件費を AI で代替 税理士の畠山謙人氏が Claude Code で構築した AI 経理システムの事例が注目を集めている（cenleaf.com の詳細記事）。 通常、税理士事務所では顧問先 10 社あたり 1 人のスタッフが必要とされる。60 社なら最低 6 人、年間人件費は約 3,000 万円。しかし Claude Code を中心とした AI システムにより、1 人で運営できる体制を実現した。 コスト削減の全体像 表面的な人件費 3,000 万円の削減だけでなく、以下の隠れたコストも消える: 採用コスト: 1 人あたり 50〜100 万円 × 6 人 = 年 300〜600 万円 労務リスク・教育・引き継ぎコスト: ゼロに 固定費から変動費への転換: 赤字耐性の向上 実際の P/L インパクトは 4,000 万円超と試算される。 自動化の仕組み 構築されたシステムでは以下を自動化している: freee の未処理明細を自動取得し、ルールベースで勘定科目を判定 判定が難しいものだけ人間に回すエスカレーション設計 請求書処理、ソフト移行、メール下書きの自動化 給与・税金・借入返済など「触ってはいけない項目」の除外ルール 重要なのは、完全自動化ではなく「人間が見る範囲を残す線引き」まで含めた仕組み化だ。 開発の民主化と IT 企業のコスト構造崩壊 この事例の本質は、税理士という非エンジニアが Claude Code で Web アプリを複数開発し、本来なら数百万〜数千万円かかる開発をほぼゼロコストで実現している点にある。 ...

AI の進化により、ソフトウェアの品質保証（QA）が根本的な転換期を迎えている。従来の「OK/NG を明確に判定する」決定論的なテストから、「明らかに間違っているものを排除する」確率論的なアプローチへ。このパラダイムシフトが QA エンジニアの役割をどう変えるのかを考える。 決定論から確率論へ 従来のソフトウェアテストは決定論的だった。入力に対して期待される出力が一意に定まり、テスト結果は OK か NG かの二択。しかし、AI を組み込んだシステムでは、同じ入力に対しても出力が毎回異なる可能性がある。 MIT Technology Review でも報じられているように、コンピューティングの世界全体が決定論的アプローチから確率論的アプローチへ移行しつつある。QA もこの流れと無縁ではない。 AI システムのテストでは、「正解を一つ定義して合否を判定する」のではなく、「明らかに間違っているものを排除し、許容範囲内に収まっているかを評価する」アプローチが求められる。 テストコードの AI 丸投げが危険な理由 「AI にテストコードを書かせれば効率的」と考えるのは自然だが、ここには大きな落とし穴がある。 AI が生成するテストコードは、実装コードに対して表面的にフィットするテストを作りがちだ。つまり、実装の動作を追認するだけのテストになりやすい。本来テストが担うべき「仕様に対する検証」や「境界値・異常系の網羅」といった設計意図が欠落する可能性がある。 テスト設計とは「何をテストすべきか」を決める行為であり、テストコードの記述は「どうテストするか」の実装に過ぎない。AI に丸投げして効率化できるのは後者であり、前者は依然として人間の判断力が不可欠だ。 テスト設計スキルの希少性 テスト設計ができるエンジニアは 100 人中 5 人程度とも言われる。この希少性は AI 時代においてむしろ差別化要因になる。 MagicPod のブログでも指摘されているように、AI が代替するのは定型的な作業だ。テスト設計・実行の自動化や不具合記録などの繰り返し業務は急速に自動化されている。一方で、以下のようなスキルは AI では代替が難しい。 リスク分析に基づくテスト戦略の策定 — どこに重点的にテストリソースを配分すべきかの判断 ビジネスコンテキストの理解 — 技術的な正しさだけでなく、ビジネスインパクトを考慮した品質判断 探索的テスト — 仕様書に書かれていない暗黙の要件やエッジケースの発見 テスト設計情報の少なさと AI の学習限界 テスト設計に関する公開情報は、コーディングに関する情報と比較して圧倒的に少ない。Stack Overflow や GitHub にはコードは大量にあるが、「なぜそのテストケースを選んだのか」「どのようなリスク分析に基づいてテスト戦略を決めたのか」といったテスト設計の知見は体系的に蓄積されていない。 つまり、AI はテスト設計を学習するための十分なデータを持っていない。これは裏を返せば、テスト設計のスキルを持つ人材の価値が AI 時代にも維持される理由でもある。 日本のテスト分析・設計の強み 日本はソフトウェアテストの分析・設計の分野で国際的にリードしている。組み合わせテスト技法、状態遷移テスト、デシジョンテーブルテストなど、体系的なテスト設計手法の発展に貢献してきた。 しかし、この強みが十分に活かされているとは言い難い。テスト設計の知見が暗黙知にとどまり、コミュニティ全体で共有・活用される仕組みが不足している。AI 時代にこの強みを活かすためには、テスト設計の知見をより体系的に言語化・公開していく取り組みが重要になるだろう。 AI エージェントによるテスト設計・実行の実践 では、実際に AI エージェントをテスト設計・実行にどう活用すべきなのか。この分野では理論と実践の両面で急速に知見が蓄積されつつある。 ...