GitHub で急速に広がっている colleague-skill（titanwings/colleague-skill）というプロジェクトがある。「辞めた同僚を AI で再現する」という見た目のインパクトだけが先行しがちだが、実装を読むと本質はもっと実務的だ。このプロジェクトが企業と個人に突きつけているのは、**「判断様式そのものを組織資産にできる時代が来た」**という問いだ。 colleague-skill とは何か titanwings/colleague-skill は、退職した同僚・前任者・メンターの仕事の進め方や話し方を、AI エージェントが呼び出せる Skill として保存するプロジェクトだ。 2026年5月時点で 18,000 stars 超、1,800 forks という数字が、この関心の高さを物語っている。 ポイントは新しいモデルを訓練しているわけではないことだ。人の暗黙知・レビュー癖・判断基準・口調を、Claude Code などで即座に呼び出せるパッケージに変換している。引き継ぎで失われがちな仕事の文脈を、実際に動く形で残すことが目的だ。 入力できるもの Feishu・DingTalk・Slack・WeChat の会話履歴、PDF、画像、メール、Markdown、手入力テキストなど幅広いソースに対応している。 Claude Code への組み込み インストールは軽量だ。 1 2 3 # ターミナルで実行 cd ~/.claude/skills git clone https://github.com/titanwings/colleague-skill . その後、Claude Code 上でスラッシュコマンドを実行する。 /create-colleague .claude/skills/ に配置して /create-colleague を実行するだけで、対話形式でスキルが生成される。 二層構造の設計：Work Skill と Persona README の設計で最も重要なのは、生成物が二つのレイヤーに分かれていることだ。 レイヤー 内容 Work Skill 担当システム、技術スタック、レビュー観点、文書作法、運用フロー、経験知 Persona 話し方、優先順位、判断癖、対人スタイル、地雷 実行順序まで定義されている。 ...

Obsidianの創業者が、自社の有料サービスである Obsidian Sync を 使わずに Vault を同期・バックアップする方法を公式ドキュメントとして明文化したことが話題になっている。 何が起きているのか Obsidian は「あなたのノートは永遠にあなたのもの」を掲げるローカルファースト型のナレッジ管理ツールだ。ノートはプレーンテキスト（Markdown）でローカルに保存され、クラウドへの依存を強制しない設計になっている。 そのObsidianの創業者が、有料の Obsidian Sync（$4〜/月・年払い、または $5/月・月払い）を契約しなくても Vault を複数デバイス間で同期できる方法を、公式ドキュメント上で余すところなく公開した。 公式が案内している無料同期の選択肢 公式ヘルプ（Sync your notes across devices）によると、以下の方法が紹介されている。 1. iCloud（Apple デバイス間） Mac・iPhone・iPad を使うユーザーにとって最もシンプルな選択肢。iCloud Drive の中に Vault フォルダを配置するだけで、Apple デバイス間でシームレスに同期される。 ~/Library/Mobile Documents/iCloud~md~obsidian/Documents/MyVault 設定コストがほぼゼロで、iOS アプリとの相性も良い。 2. Google Drive / Dropbox / OneDrive クラウドストレージのフォルダ配下に Vault を置くだけで同期が成立する。Windows や Android ユーザーにも対応できる汎用的な方法だ。 Google Drive のデスクトップアプリで同期するフォルダを指定 Vault を ~/Google Drive/MyVault などのパスに配置 モバイルでは公式の Obsidian アプリ + ファイルマネージャアプリで Vault フォルダを指定 3. Git（バージョン履歴も残したい人向け） obsidian-git プラグインを使えば、Vault の変更を GitHub などに自動プッシュできる。 1 2 3 4 # プラグイン設定後、Vault ルートで初期化 git init git remote add origin https://github.com/yourname/my-vault.git git push -u origin main プラグイン設定で自動コミット・プッシュ間隔を指定できるため、バージョン履歴まで残せる点が他の方法と異なる。 ...

Anthropic の研究・プロダクトチーム（Barry Zhang・Mahesh Murag）が、2025年11月の AI Engineering Code Summit で衝撃的な発言をした。 「Agents をやめて、Skills に全振りした」 Agent ツールを実際に開発してきた当事者が、この言葉を口にした意味は重い。単なる命名変更ではなく、AI 自動化の設計哲学そのものが変わった瞬間だ。 この記事では、なぜ Anthropic が Agents から Skills へシフトしたのか、その背景と技術的な理由、そして今すぐ自分のワークフローに活かせるポイントを解説する。 Agents の限界 — 何が問題だったのか 従来の「Agent」アプローチの核心は、中央集権型オーケストレーターだった。1 つの LLM が多数のツールを持ち、あらゆるタスクに対応しようとする構成だ。具体的には以下の 4 点が問題になった。 ツールオーバーロード: ツール数が増えるほど、LLM はどのツールを使うべきか判断しにくくなる 再現性の低さ: 複雑なシナリオで中央オーケストレーターが混乱し、同じ入力に対して異なる結果が出やすい モデル依存: Claude 専用に設計された Agent は、他のモデルでは動かない コンテキスト肥大化: すべての能力を一度にロードするため、トークンが無駄に消費される Barry Zhang と Mahesh Murag はこれらの問題を実装レベルで体験し、「根本から再設計が必要だ」という結論に至った。 Skills とは何か — Agent との本質的な違い Skills は、Claude Code の拡張機能の単位だ。SKILL.md と必要なスクリプト・設定ファイルを 1 つのフォルダにまとめて定義し、必要なときだけオンデマンドでメイン会話コンテキストに注入される。 観点 Agents Skills 設計思想 中央集権型オーケストレーター モジュラー・再利用可能な能力単位 モデル対応 Claude 専用 Claude + 他モデル両対応 実行コンテキスト 独立した隔離環境 メイン会話内（記憶・フォローアップが可能） ロード方式 常時ロード オンデマンド（トークン節約） 再現性 複雑なシナリオで低下しやすい 実用レベルで高い 最も重要な変化はモデル非依存になったことだ。Anthropic は 2025年12月に Skills をオープンスタンダードとして agentskills.io で公開し、Microsoft/VS Code・OpenAI・Cursor・GitHub・Google Gemini CLI・JetBrains Junie など主要プラットフォームが採用済みだ。Claude だけでなく、他のモデルでも同じスキルが動作する。 ...

TL;DR: SOPS で暗号化していた API トークン複数種が GitHub Actions の workflow log に平文で露出した。原因は 「masking 登録ループが存在しない一時ファイルから読まれていて空回りしていた」 という pre-existing なバグ。gh run delete でログ削除 + 該当 secrets を rotate して被害を抑制。再発防止のため 構造的予防 (source-from-file) + 静的検知 (lint) + ドキュメントルール + PR レビュー時 security review の 4 層で対策。 0. 文脈 ある社内自動化基盤の Phase 0 検証中、workflow_dispatch で配信 workflow の dry_run を初めて起動したところ、復号済 secrets が workflow ログの env header に平文表示された。本記事はその post-mortem である。 技術スタック: GitHub Actions (Linux runner) SOPS + age による secrets 暗号化（リポ内 commit） LLM ベースの workflow agent (custom action 経由) による skill 実行 メッセージング基盤 / CRM / 課題管理 SaaS への API トークン群 1. 何が起きたか dry_run 検証で起動した workflow の途中 step、Run skill step の env: block 表示で複数の API トークンが平文表示された: ...

この記事では、147万ビューを集めたバイラル投稿の信憑性をコミュニティノートとともに検証し、AIコンテンツ自動化の現実的なスケールを整理する。 バイラル投稿の概要 2026年5月、X（旧Twitter）でこんな投稿（トルコ語、以下意訳）が拡散した。 ロサンゼルスに住む7人の若者が、Claudeだけを使ってeブックを販売し、合計6500万ドル（約95億円）を稼いだ。なぜか誰もこれを話題にしていない。 従業員なし。オフィスなし。大学卒業者ひとりもいない。Claudeで1日わずか45秒で300本のコンテンツを生成し、1500万以上のオーガニックビューを獲得。 でも彼らは毎日何百ものコンテンツを手動で投稿していたわけではない。 代わりに、あるシステムを構築した：Claude + コンテンツ生成フロー + 完全自動化システム この投稿は147万以上のビューを記録し、4000件以上のいいね、9500件以上のブックマークを集めた。 コミュニティノートの警告 しかし、この投稿にはコミュニティノートが付いている。 ロサンゼルスに住む7人の若者がClaude eブック販売で6500万ドルを稼いだという主張は、独立した情報源によって検証されていません。このストーリーはマーケティング目的のXの投稿にのみ存在します。 要するに、この主張は裏付けがない。公式な財務報告も、独立した報道も存在しない。「誰かがバイラルを狙って作り上げた話」である可能性が高い。 こうした「AIで億万長者」系の投稿は定期的に出回るが、その多くはコンサルティングやコース販売への誘導が目的だ。実際、この投稿の最後も「どうやってやったか説明します」という続きがある構造になっている。 ではAIによるコンテンツ自動化は嘘か？ しかし、自動化そのものは実在する技術だ。 ただし、現実的なスケールの話として捉え直す必要がある。 Claudeなどの大規模言語モデルを使ったコンテンツ生産の自動化は、実際に多くの企業や個人が取り組んでいる分野だ。正確には以下のような流れになる。 典型的なコンテンツ自動化パイプライン テーマ選定 — トレンドキーワードのスクレイピング、競合分析、ニッチ市場の需要調査 コンテンツ生成（Claude API） — アウトライン生成、各章の本文生成、タイトル・見出しの最適化、SEO向けキーワード埋め込み レビュー・品質チェック — ファクトチェック、読みやすさのスコアリング、重複チェック 配信・販売 — Amazon KDP / Gumroad への自動アップロード、SNSへの告知コンテンツ自動生成、メールマーケティングとの連携 現実的な成果スケール 1日300本の「コンテンツ」：短いSNS投稿なら不可能ではないが、品質管理が追いつかない 45秒でeブック1冊：完成品は難しい。アウトラインや章の一部なら可能 6500万ドル：eブックのみでこの売上は極めて異例。多くのメガ出版社でもこの規模は数年かかる 実際にAIコンテンツ自動化で成功している事例は存在するが、月収数百万円〜数千万円規模が現実的なトップライン。「6500万ドル」は検証されていない数字だ。 Claude APIを使った実際のeブック自動化 現実的な範囲でClaudeを活用するとしたら、以下のようなアプローチが有効だ。 シンプルなeブック生成スクリプト 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 import anthropic client = anthropic.Anthropic() def generate_ebook_outline(topic: str) -> str: message = client.messages.create( model="claude-opus-4-7", max_tokens=2048, messages=[ { "role": "user", "content": f"""以下のトピックについて、商業用eブックのアウトラインを作成してください。 トピック: {topic} 要件: - 章数: 7〜10章 - 各章に2〜3のサブセクション - 実践的な内容を重視 - 読者ターゲットを明確に Markdown形式で出力してください。""" } ] ) return message.content[0].text def generate_chapter(outline: str, chapter_title: str, word_count: int = 1500) -> str: message = client.messages.create( model="claude-opus-4-7", max_tokens=4096, system="あなたはプロのライターです。実践的で価値のあるコンテンツを書いてください。", messages=[ { "role": "user", "content": f"""以下のeブックの章を執筆してください。 全体アウトライン: {outline} 執筆する章: {chapter_title} 目標文字数: 約{word_count}文字 具体例や実践的なアドバイスを含めてください。""" } ] ) return message.content[0].text プロンプトキャッシュを活用した効率化 大量生成する場合は、プロンプトキャッシュを活用するとコストを大幅に削減できる。 ...

概要 2026年5月20日、スペイン語圏のテックメディア @CopyRebeldia が衝撃的なポストを投稿した。 「今日、業界ひとつまるごと意味を失った。Meta が SAM3 を GitHub で公開した。『白いユニフォームの選手』と言うだけで、NBA の混戦の中からその選手だけを追跡し、戦術図まで重ね描いてくれる。手動スカウティングはもう趣味になった。」 このデモ動画を投稿したのは Roboflow のオープンソースリード Piotr Skalski（@skalskip92）。わずか 19 秒の映像が、コンピュータビジョン界隈に大きな波紋を呼んだ。 本記事では Meta SAM3 の仕組みと、スポーツ分析をはじめとする実用分野への影響を解説する。 SAM3 とは SAM3（Segment Anything Model 3） は Meta AI Research が開発したモデルだ。画像・動画を対象に、物体の検出・セグメンテーション・追跡を一つのモデルに統合している。 公開日: 2025年11月19日（SAM 3.1 は 2026年3月27日） GitHub: facebookresearch/sam3 論文: SAM 3: Segment Anything with Concepts 前世代の SAM2 と比べた最大の変化は「テキストプロンプトで物体を指定できる」点だ。 SAM2 との違い SAM2 SAM3 プロンプト形式 点・ボックス・マスク（空間的） テキスト・サンプル画像・空間的 セマンティック理解 なし あり（オープン語彙） 複数物体追跡 品質低下あり Object Multiplex で並列追跡（3.1〜） 言語エンコーダ なし 大規模テキストエンコーダ統合 カモフラージュ物体 検出困難 検出可能 SAM2 は「この座標にある物体を追え」という指示しかできなかった。SAM3 は「白いユニフォームを着た選手」「ボールを持っている人」という意味的な概念で物体を特定できる。 ...

はじめに AIブームが引き起こした「電力テーマ」は、単なる半導体株の上昇にとどまらず、複数のセクターを順番に押し上げるセクターローテーションとして進行しています。 株式市場で成果を出している投資家の間で「半導体はもう買っていない」という声が増えています。なぜか。答えはシンプルで、上がる前に買うという鉄則を実践しているからです。 この記事では、AI電力テーマのセクターローテーション4段階の構造と、現在の注目フェーズである蓄電池への移行ロジック、そして「上がる前に仕込む」実践的な視点を解説します。 AI電力テーマのローテーション構造 AI電力テーマは次の4段階でセクターを移動していると分析されています。 各フェーズを順番に見ていきます。 第1フェーズ：半導体 AIの計算需要が爆発的に増大し、NVIDIAのGPUや関連半導体株が急騰しました。ChatGPT登場以降のAIブームをけん引した最初の波です。この段階では「AI = 半導体」という図式が定着し、多くの資金が流入しました。 しかし、すでに市場価格に織り込まれており、上昇余地が限定的になってきています。賢い投資家はここから次のフェーズへ資金を移動させています。 第2フェーズ：データセンター建設・REIT AIを動かすには大量のサーバーを収容するデータセンターが必要です。建設・不動産投資信託（REIT）セクターへの資金移動が起きました。Alphabet・Amazon・Microsoft・Metaによるデータセンター投資拡大の発表が相次ぎ、関連銘柄が注目を集めました。 第3フェーズ：発電・電力株 データセンターの電力消費は膨大です。米国では三マイル島原発の再稼働（Microsoftとの長期契約）や小型モジュール炉（SMR）への投資発表など、電力インフラへの関心が高まりました。日本でも原発再稼働の動きが加速し、発電会社や電力関連インフラ株がこのフェーズの主役となりました。 第4フェーズ：蓄電池（現在進行中） 現在注目されているのが蓄電池セクターです。 電力需要の増大に対して、安定した電力供給を実現するには蓄電技術が不可欠です。再生可能エネルギーの出力変動を平準化し、データセンターの無停電を支える基盤として、蓄電池の重要性が増しています。 なぜ蓄電池が次のフェーズなのか 電力安定化の需要 太陽光・風力など再生可能エネルギーは発電量が天候に左右されます。データセンターのような24時間365日稼働が必要な施設には、安定した電力供給が不可欠です。電力会社レベルの大規模蓄電（グリッドスケールESS: Energy Storage System）が、この変動を吸収する役割を担います。テスラのMegapackに代表されるユーティリティスケール蓄電製品への需要が世界的に拡大しています。 EV・モビリティとの相乗効果 電気自動車（EV）の普及加速も蓄電池需要を押し上げています。EV向けと定置型蓄電はどちらもリチウムイオン技術を基盤としており、製造規模の拡大がコスト低下に相乗効果をもたらしています。ただし化学系統には差異があり、EV向けはNMC（ニッケル・マンガン・コバルト）、定置型蓄電はLFP（リン酸鉄リチウム）が主流です。テスラ自身もMegapackをLFP系統に切り替えており、安全性・コスト面でのLFP優位性が定置型市場のトレンドとなっています。 グリッドレベルの蓄電 電力会社レベルの大規模蓄電への投資も世界的に拡大しています。再生可能エネルギーの比率が上がるほど、出力変動を吸収する蓄電インフラの整備が急務となるためです。 「上がる前に買う」という鉄則 セクターローテーションで重要なのは次に資金が流入するセクターを先読みすることです。 すでに上昇したセクターに遅れて入るのは、リスクとリターンのバランスが悪化します。先行して動いた投資家が利益確定に動く場面で、後から入った投資家が損失を被る構図になりがちです。 セクターローテーションを意識した投資では、以下の4点を意識します。 現在の主役セクターを把握する — 今どこに資金が集中しているか 次の受益セクターを特定する — インフラ整備の連鎖を読む 材料出尽くし前に仕込む — ニュースが広まる前に入る 過熱感を見極めて乗り換える — 次のフェーズへの移動タイミングを逃さない まとめ AI電力テーマのセクターローテーションは「半導体 → データセンター → 電力 → 蓄電池」という流れで進行しており、現在は蓄電池フェーズにあるとされています。 投資で成果を上げる人たちに共通するのは、注目が集まる前に動き、注目が集まったときに次を見ているという姿勢です。「上がってから買うのではなく、上がる前に買う」——この原則はセクターローテーション戦略の本質を突いています。 もちろん、投資判断は自己責任であり、相場には常に不確実性があります。セクターローテーションの読みが外れることもありますが、市場のテーマ性と資金の流れを理解しておくことは、投資戦略を立てる上での重要な視座になります。 参考: @KB_Hiragi さんのポスト (X)

AIに「作らせる」だけでは足りない時代 AIコーディングツール（Claude Code、Codex、Cursor など）を使う際、多くの開発者が次のプロンプトで止まってしまっている。 1 2 3 「作って」 「修正して」 「いい感じにして」 これで機能は動く。しかし、後から「なぜそうなったのか」が一切わからない。 Claude Code Studio（@ClaudeCode_love）が紹介した、Anthropic 社員が使っているとされるプロンプトは、その問題に真正面から切り込んでいる（公式声明ではなく、あくまで伝聞である点に注意）。 Anthropic 社員が使うプロンプト 元ツイート（2026-05-19）では「自分がいちばん使っているプロンプト」として次の指示が紹介されている。 1 2 3 仕様書通りに実装して。 その途中で、仕様書に書かれてなかった判断・変更・妥協点・意思決定を、 全部 implementation-notes に残して 英語で書くなら次のようになる。 1 2 3 Implement according to the specification. Along the way, record every judgment, change, trade-off, and decision not covered by the spec into implementation-notes. 一見地味に見えるが、これは AI コーディングの本質を突いたプロンプトだ。本記事では、このプロンプトを 「計画レビュー」と対比する形で深掘り し、なぜ AI コーディング時代に implementation-notes パターンが支配的になるのかを考察する。 ...

2026-05-27 追記: 実際にインストールしてみたところ、デフォルトのままでは TinyHumans へのサブスク課金（=有料アカウント）が必要なことが判明した。GPL-3 のオープンソースなのになぜ有料なのか、本記事に「なぜ TinyHumans への課金が必要なのか」セクションを追加した。「完全ローカル」を額面どおりに実現するための回避ルートも併記している。 「クラウドAIに自分の悩みを打ち明けるのが不安」という声をよく聞く。仕事の機密、家族の話、健康上の悩み——ChatGPTに投げてはみるものの、その会話がサーバーに残り続けることへの抵抗感は根強い。 そこに登場したのが OpenHuman だ。GitHubスター数2.7万を超え、週に1,000以上のペースで増え続けるこのプロジェクトは、「ChatGPT級のAIを完全にローカルで動かす」という問いへの実践的な回答を提供している。 OpenHumanとは OpenHuman は、TinyHumans AIが開発するオープンソースのエージェント型AIアシスタントだ。Rustをコアに持ち、デスクトップアプリとして動作する。 公式の説明は簡潔にまとめられている。 Your Personal AI super intelligence. Private, Simple and extremely powerful. ポイントは3点だ。 Memory Tree による長期記憶 Obsidianスタイルのローカルナレッジベース 118以上のサービス連携 これらを組み合わせることで、「インストールから数分でユーザーを知り尽くしたエージェント」を目指している。 なぜ「ローカルAI」が重要なのか ChatGPTをはじめとするクラウドAIの課題は、会話が外部サーバーへ送信される点にある。個人情報保護の観点から問題となるだけでなく、企業での利用では情報漏洩リスクが伴う。 OpenHumanが解決しようとしているのはこの点だ。 会話を外に出さない構成が選べる — ローカルLLM（Ollama / LM Studio経由）を選択すれば推論まで自機で完結する データは自分のPCに保存される — Memory Tree DB と Markdown Vault はローカルファイルとして残る 日本語README完備 — 日本語ユーザーへの配慮も行き届いている Rust製で爆速 — コアがRustで書かれており、動作が軽快 ただし注意点がある。デフォルト構成では「サインイン」「モデルルーティング」「Web検索プロキシ」「Composio経由のOAuth/ツール連携」がすべてOpenHuman（TinyHumans）社のマネージドバックエンドを経由する。つまり初回起動時に TinyHumans アカウントを作って有料サブスクに入らないと、せっかくのMemory TreeもAuto-fetchも動かない。「完全オフライン」を額面どおりに実現するには、ローカルモデル＋Composio直接モード＋自前のWeb検索APIキー、といった追加設定が必要になる。詳細は後述する。 主な機能 Memory Tree + Obsidian Vault OpenHumanの中核機能は Memory Tree だ。接続した各種サービスから取得したデータを3,000トークン以内のMarkdownチャンクに圧縮し、SQLiteに階層的に保存する。同時に、Obsidianと互換性のある .md ファイルとしてローカルVaultへ書き出す。 ...

「Claude に作らせたアプリを即デプロイして稼ぐ」——この流れが加速する一方で、セキュリティや法的義務を丸ごとスキップしたまま本番リリースしてしまうケースが急増している。トルコのデザイン系インフルエンサー Yiğit Akın Kaya が X（旧Twitter）に投稿した辛辣なツイートが、エンジニアコミュニティで話題になっている。 「バイブコーダーに悲しいお知らせ。Claude にアプリを作らせて即リリース、即マネタイズしようとしていた連中が、次々と法廷に引きずられ始めている」 この記事ではそのツイートをもとに、AIで高速開発したアプリを本番公開する前に必ず確認すべきセキュリティチェックリストを日本語でまとめる。 なぜ今、バイブコーダーが訴訟リスクを抱えるのか Claude や GPT-4o などの LLM を使えば、数時間でそれなりの外観と機能を持つ Web アプリが作れる。しかしツイートが指摘するように、開発者の多くが「派手なUI」には投資するが「退屈なセキュリティと基盤」はスキップしてしまう。 問題は、セキュリティ上の欠陥はサービス開始後に顕在化することだ。個人情報漏洩・不正アクセス・著作権侵害・プライバシーポリシー不備——これらは各国の規制（日本なら個人情報保護法、EUなら GDPR など）に抵触し、法的責任を問われる。 本番公開前に確認すべき5つのセキュリティチェックリスト ツイート原文（トルコ語）では 5 つの項目が挙げられている。日本のコンテキストに合わせて補足する。 1. SQL インジェクションと XSS の脆弱性スキャン LLM が生成するコードは、入力値の検証やエスケープ処理を省略しがちだ。 1 2 3 # OWASP ZAP による簡易スキャン例 docker run -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py \ -t https://your-app.example.com SQL インジェクション: ORM やプリペアドステートメントを使っているか確認する。生の文字列結合で SQL を組み立てていたら即アウト。 XSS: ユーザー入力を HTML に埋め込む箇所では必ずエスケープ処理を入れる。React / Vue はデフォルトで対策済みだが、dangerouslySetInnerHTML や v-html の使用箇所は要チェック。 2. .env ファイルの漏洩防止 API キーやデータベース接続文字列が .env ファイルに入っていたとして、それが意図せず公開されていないか確認する。 ...