記事一覧

Andrej Karpathy が2026年4月に公開した GitHub gist「LLM Wiki」が、公開から48時間以内に5000スターを超えた。コード一行も含まない、純粋にアイデアだけを記述したドキュメントがここまで反響を呼んだ理由はシンプルだ。「RAGの次」を具体的かつ実践的に示していたからである。 RAGとの決定的な違い 多くの人がLLMとドキュメントを組み合わせるとき、最初に試みるのが RAG（Retrieval-Augmented Generation） だ。ChatGPTのファイルアップロード、NotebookLM、LangChainで構築するベクトルDB検索 — これらはすべて「質問が来たときにドキュメントから関連部分を取ってきて回答する」という設計思想に基づいている。 この方式には根本的な問題がある。知識が蓄積されない。5つのドキュメントを横断する微妙な問いに対しても、LLMは毎回ゼロから関連箇所を探し出し、推論し直す。「矛盾」も「文脈」も「先週気づいた発見」も、次の質問では消えてしまう。 LLM Wiki が提案するのは根本的に異なるアプローチだ。 LLM が incrementally に永続的な wiki を構築・維持する。新しいソースを追加するたびに、LLM はそれを読み込んで既存 wiki に統合し、エンティティページを更新し、矛盾を記録し、進化する合成の全体を強化する。知識は毎回再導出されるのではなく、一度コンパイルされてから最新に保たれる。 この「コンパイルされた知識ベース」こそが LLM Wiki の本質である。 3層アーキテクチャ LLM Wiki は3つの層で構成される。 1. Raw Sources（生ソース） 記事、論文、画像、データファイルなど自分がキュレートしたソースドキュメントの置き場。不変（immutable） — LLMはここから読むだけで決して書き換えない。これが「真実の源泉」となる。 2. The Wiki（wiki本体） LLM が生成・維持するマークダウンファイルの集合。概要、エンティティページ、概念ページ、比較、合成。この層は LLM が完全に所有 する。あなたは読む側で、LLM が書く側だ。 3. The Schema（スキーマ） CLAUDE.md（Claude Code用）や AGENTS.md（Codex用）など、LLMに wiki の構造・規約・ワークフローを伝えるドキュメント。これが LLM を「汎用チャットボット」から「規律あるwikiメンテナ」に変える鍵だ。このファイルはあなたと LLM が協力しながら進化させていく。 3つの操作 Ingest（取り込み） 新しいソースを生コレクションに追加して、LLMに処理を依頼する。LLMはソースを読み込み、重要な情報を抽出し、wikiに統合する。一つのソースが10〜15のwikiページを更新することもある。一度に大量のソースをバッチ処理することも可能だが、Karpathy 自身は「一つずつ取り込み、要約を確認しながら進める」スタイルを好むと述べている。 Query（クエリ） wikiに対して質問する。LLMは関連ページを検索・読み込み、引用付きで回答を合成する。回答の形式は問いによって変わる — マークダウンページ、比較表、Marpスライド、matplotlibグラフなど。 重要な洞察: 良い回答はwikiに新しいページとして追記できる。「あの比較をお願いした結果」「見つけた新しい接続」— これらをチャット履歴に埋もれさせるのではなく、wikiに蓄積させることで探求が複利的に積み重なる。 ...

複数の AI コーディングエージェントを使い分けるのは手間がかかる。その課題を解決するのが oh-my-openagent（omo） だ。Claude Code・OpenAI Codex・Gemini CLI といった主要エージェントを一元管理し、タスクに応じて最適なモデルへ自動ルーティングするオープンソースのハーネスで、GitHub スター数は 5.7 万超（2026 年 5 月時点）に達している。 oh-my-openagent とは oh-my-openagent は、もともと oh-my-opencode という名称で 2025 年 12 月に登場し、その後マルチエージェント対応を強化するかたちでリブランドされたツールだ。 作者: code-yeongyu 言語: TypeScript ライセンス: SUL-1.0 公式サイト: ohmyopenagent.com キャッチフレーズは「the best agent harness」。単一のエージェントに何でも任せるのではなく、専門化されたエージェント群がタスクを分担し、並列実行することで開発速度と品質を両立させる設計思想を持つ。 対応エージェントとプロバイダー oh-my-openagent は以下のエージェント・モデルプロバイダーに対応している。 プロバイダー 主なモデル Anthropic Claude Code（claude-opus-4-6 / 4-7 等） OpenAI Codex、GPT-5.5 Google Gemini CLI GitHub Copilot その他 Kimi K2、DeepSeek V4 等 インストール時に利用中のサブスクリプションプラン（Claude Pro/Max、ChatGPT Plus など）を選択することで、利用可能なプロバイダーのみを有効化できる。 主要機能 マルチモデルオーケストレーション タスクの種類ごとに最適なモデルを自動選択する「カテゴリベースのモデル割り当て」が核心機能だ。 visual-engineering（フロントエンド・UI 実装）→ Gemini ultrabrain（高難度なアーキテクチャ設計）→ Claude Opus 4.7 artistry（クリエイティブな文章生成）→ GPT-5.5 deep（深い推論・リサーチ）→ Claude Opus / Kimi K2 コスト最適化の観点から、大量ファイル生成のような作業は DeepSeek V4-Flash などの安価なモデルに自動振り分けされる。 ...

RBAC（Role-Based Access Control：ロールベースアクセス制御）とは、ユーザーに直接権限を与えず、ロールを介して権限を管理する仕組みです。 AWS の IAM、Kubernetes、GitHub、Microsoft 365 など、現代のほとんどのプラットフォームがこの考え方を基盤にしています。 一言で言うと、「社員一人ひとりに鍵を渡すのではなく、役職ごとのマスターキーを管理する」仕組みです。本記事では RBAC の基本構造、必要性、ABAC との違い、AWS IAM・Kubernetes での実装例までをまとめます。 RBAC の基本構造 RBAC は主に 3 つの要素の組み合わせで成り立っています。 ユーザー (User) — システムを利用する個人 ロール (Role) — 「管理者」「編集者」「閲覧者」といった役割。権限の集合体 パーミッション (Permission) — 「ファイルの読み取り」「データの削除」といった具体的な操作権限 ユーザーは直接パーミッションを持つのではなく、ロールを介して権限を獲得します。この「間接化」が RBAC の本質です。 なぜ RBAC が必要なのか 従来の ACL ベースの管理（ユーザーごとにリソースの権限を個別に設定する方式）では、組織が大きくなるにつれて管理が破綻します。RBAC を導入することで、以下のメリットが得られます。 1. 管理の効率化 異動や入社があった際、個別に何十もの設定を変更する必要がなく、適切な「ロール」を割り当てるだけで済みます。退職時もロールを外せば一括で権限が剥奪されます。 2. セキュリティの向上（最小権限の原則） 業務に必要な権限だけをセットにしたロールを作成することで、過剰な権限付与によるリスクを防げます。最小権限の原則（Principle of Least Privilege）を組織的に実現する手段として最も普及しているのが RBAC です。 3. コンプライアンスの強化 「誰がどのような権限を持っているのか」をロール単位で把握できるため、監査が容易になります。SOC 2、ISO 27001、PCI DSS などのコンプライアンス監査では、アクセス権限のレビューが必須項目になっており、RBAC ベースの設計だとレポート作成が圧倒的に楽になります。 具体例：ドキュメント管理システム ユーザー 割り当てられたロール 実行できる操作 (パーミッション) 佐藤さん 管理者 (Admin) 作成、編集、削除、ユーザー追加 鈴木さん 編集者 (Editor) 作成、編集 高橋さん 閲覧者 (Viewer) 閲覧のみ もし鈴木さんが管理者に昇進した場合、鈴木さんの設定を一つずつ変えるのではなく、付与するロールを「編集者」から「管理者」へ切り替えるだけで、すべての権限が更新されます。 ...

IoT システムや SaaS の提案書を書いていると、お客様から「このシステム、ちゃんと動くんですか?」と聞かれます。この質問にどう答えるか で、契約交渉の主導権が決まります。 「99.9% 動きます」と言い切れば SLA（契約）になり、下回ったら違約金。「目標値です」と言えば SLO（内部目標）で、未達でも返金義務はない。この 1 文字違いで法的拘束力が変わります。 本記事では、SRE（Site Reliability Engineering）業界で標準となっている SLI / SLO / SLA の 3 用語の 違いと使い分け を、提案書を書く立場から整理します。 3 用語の違い（要点） 略語 正式名 一言で 性格 SLI Service Level Indicator 計測する指標 データ SLO Service Level Objective 目指す目標 内部約束 SLA Service Level Agreement 契約上の保証 対外契約 順序は SLI → SLO → SLA で考えます。 SLI で「何を測るか」を決める（例: イベント検知から通知メール送信までの遅延時間） SLO で「目標値」を内部で握る（例: 95%ile が 60 秒以内） SLA で「契約条項」に格上げする（例: SLO 違反が月 3 件超えたら月額の 10% 返金） なぜ 3 つに分かれているのか Google SRE Book が提唱した「エラーバジェット」の考え方が背景にあります。 ...

香港大学データインテリジェンスラボ（HKUDS）が開発したオープンソースの動画生成フレームワーク ViMax が GitHub で急速にスターを伸ばしている（3,800超・MIT ライセンス）。1行のテキストアイデアを入力するだけで、脚本執筆・絵コンテ設計・キャラクター管理・最終動画レンダリングまでを自律的に実行するエンドツーエンドのマルチエージェントシステムだ。 ViMax とは ViMax（Video Maximizer）は「Director（監督）・Screenwriter（脚本家）・Producer（プロデューサー）・Video Generator（映像生成）をひとつに」という設計コンセプトで開発された動画生成フレームワークだ。従来、テキストから動画を生成するには複数のツールを組み合わせる必要があった。ViMax はそのパイプライン全体をマルチエージェント構成で自動化する。 GitHub: HKUDS/ViMax ライセンス: MIT 言語: Python 3.12+ Stars: 3,852+（2026年5月時点） 4つの生成モード ViMax には入力形式に応じた 4 つのモードが用意されている。 Idea2Video 1 行の概念・プロンプトを入力すると、ストーリーテリング・キャラクターデザイン・動画制作まで完全自動化される。「アイデアをそのまま映像に」したいユーザー向けのモードだ。 Novel2Video 小説の章や全文を入力すると、エピソード形式の動画に変換される。RAG（検索拡張生成）ベースのナラティブ圧縮機能でキャラクターの登場追跡とシーンごとの視覚的解釈を行う。長編小説の映像化に適している。 Script2Video ユーザーが書いたシナリオを動画化する。シーン・セリフ・スタイルを明示的に指定でき、映像表現への細かいコントロールが可能。 AutoCameo 自分の写真をアップロードすると、生成された動画に本人が一貫したキャラクターとして登場する機能。個人の顔や姿を主人公として組み込める。 主要な技術的特徴 インテリジェントな長編スクリプト生成（RAG ベース） 小説規模のテキストを解析し、マルチシーン形式に分割する。重要な伏線やキャラクターの台詞を保持しながら、映像に適した脚本へ変換する。 表現力豊かな絵コンテ設計 ショットレベルの絵コンテシステムに映画製作の語彙（カメラアングル・カット・テンポ・ナラティブリズム）を採用している。 マルチカメラ撮影シミュレーション 同一シーン内でのキャラクター配置・背景の一貫性を保ちながら、複数のカメラアングルをシミュレートする。 インテリジェントな参照画像選択 タイムライン上の過去の絵コンテを参照画像として自動選択し、長尺動画でもキャラクターや背景の整合性を維持する。 並列候補生成 + MLLM による一貫性チェック 複数の候補画像を並列生成し、マルチモーダル LLM（MLLM — テキストと画像を同時に扱える大規模言語モデル）が最も一貫性の高い画像を選択する。人間のクリエイターのレビューワークフローを自動化したアプローチだ。 並列ショット生成による高速化 同じカメラからの連続するショットを並列処理することで、生成時間を大幅に短縮する。 音声・映像バインディング 音声・効果音・映像を同期させ、没入感のある最終出力を生成する。 マルチエージェントパイプラインの構造 ViMax の処理パイプラインは以下の層で構成されている。 インストールと設定 動作環境: Linux または Windows / Python 3.12+ / uv（Astral パッケージマネージャー） ...

概要 インターネットから物理的に切り離されたコンピュータ（エアギャップ PC）は、長らく「最後の砦」とされてきた。しかしイスラエルのベングリオン大学 Cyber Security Research Center のチームは、CPU の負荷変動が生む低周波磁場を使ってデータを外部に送信する 概念実証マルウェア「ODINI」を開発し、その限界を根本から問い直した。 同チームが 2018 年に arXiv で公開し、2020 年に IEEE Transactions on Information Forensics and Security に掲載された本研究は、ファラデーケージで遮蔽された機器からさえもデータを盗み出せることを実証している。 エアギャップとは何か エアギャップ（air gap）とは、ネットワーク接続を一切持たない状態でコンピュータを運用する手法だ。核施設の制御システム、軍の機密端末、金融機関のコアシステムなどで採用される。ファラデーケージ（電磁シールドされた筐体）と組み合わせることで、電波による傍受にも対応できる「究極の隔離」とみなされてきた。 ODINI の攻撃原理 CPU 負荷 → 電力消費 → 磁場変動 ODINI が悪用するのは、CPU が集中的な演算を行うと電力消費が増加し、低周波の磁場変動 が生じるという物理現象だ。 感染済みの PC — 事前に何らかの手段（USB、サプライチェーン攻撃など）でマルウェアを仕込む CPU コアへの意図的な負荷 — マルウェアが CPU コアに高負荷演算を繰り返し課し、電力消費を人工的に変動させる 磁場へのデータエンコード — ASK（振幅偏移変調）や FSK（周波数偏移変調）を使い、盗み出したいデータをビット列として磁場のパターンに乗せる 外部からの受信 — 攻撃者側は磁気センサーをそばに持ち込み、変調された磁場を受信してデータを復元する この手法の核心は「低周波磁場」にある。高周波電磁波はファラデーケージで容易に遮断できるが、低周波磁場はインピーダンスが非常に低く、金属筐体を含む物理的シールドを貫通してしまう。 主要スペック 項目 値 データレート（最大） 40 bps 受信可能距離 約 100〜150 cm 必要な権限 不要（一般ユーザー権限で動作） ファラデーケージの遮蔽効果 無効（低周波磁場は通過） 管理者権限が不要という点が特に厄介だ。攻撃コードは通常の演算処理を模倣するため、プロセス監視だけでは検知が難しい。 ...

2026 年 3 月、Anthropic は Claude Code の思考深度（thinking effort）のデフォルト値を high から medium に静かに変更した。 リリースノートには目立つ記述がなく、多くの開発者は「最近 Claude の質が落ちた気がする」と感じながら原因を見つけられずにいた。 Claude Code の開発者である Boris Cherny 氏が Hacker News でこの変更を認め、その後 AI 開発者コミュニティで 15 の重要設定がまとめられて話題になった。 本記事ではそれらを日本語で解説する。 1. 思考深度（effort level）の復元 問題： 2026 年 3 月以降、デフォルトが medium に変更された。Claude の思考回数が減り、コードの質・ツール呼び出し数・コメントの充実度すべてが低下している。 修正方法： セッション内で一時的に変更する場合は /effort high、恒久的に変更する場合はシェル設定に追記する。 1 export CLAUDE_CODE_EFFORT_LEVEL=high 本格的なコーディング作業では high または max を設定することで、2026 年 2 月以前の品質に戻せる。 2. Adaptive thinking の無効化 問題： 2026 年 2 月以降、Claude はタスクの複雑さを自己判断して推論量を動的に調整するようになった。「簡単なタスク」と判断した場合はほぼ思考せず、バグを見逃すことがある。 ...

元AppBankのYouTuber・マックスむらい氏（@entrypostman）が、2026年1月13日から始めた米国株投資の4ヶ月間の実績をXで公開した。最大で約1,700万円の含み損を経験しながらも、2026年5月8日時点で含み益3,000万円超を記録している。 投資開始の経緯と方針 マックスむらい氏は2026年1月13日に米国株投資を開始。方針は明確で「テンバガー（10倍株）以外は目指さない」というもの。分散よりも集中投資を選び、宇宙・量子コンピュータ関連の成長株6銘柄に絞り込んでいる。 4ヶ月間の軌跡 時期 状況 2026年1月 米国株投資スタート 2026年2〜3月 中東情勢悪化などで最大含み損 約▲1,700万円 2026年5月8日時点 含み益 約+3,000万円超 投資開始直後に大きな含み損を抱えたものの、そのまま保有し続けることで反転。総資産は約1億4,500万円に達したと報告されている。 集中投資する6銘柄 宇宙関連株（4銘柄） Rocket Lab（$RKLB） — 小型ロケット打ち上げ企業 AST SpaceMobile（$ASTS） — 衛星ブロードバンド通信 Intuitive Machines（$LUNR） — 月面着陸船の開発・運用 RedWire（$RDW） — 宇宙インフラ・部品メーカー 量子コンピュータ関連株（2銘柄） IonQ（$IONQ） — イオントラップ方式の量子コンピュータ SEALSQ（$LAES） — ポスト量子暗号チップ・量子セキュリティ半導体 これらはいずれも高ボラティリティ銘柄であり、短期的な価格変動が非常に大きい。氏は高いボラティリティを承知の上で長期保有を続けていると述べている。 moomoo証券とのスポンサーシップ発表 今回の投稿では、moomoo証券とのスポンサーシップ締結も同時に発表された。氏はYouTubeチャンネル「マックスむらいの宇宙株LIVE」を立ち上げ、米国株の定期ライブ配信を開始する予定だ。 ファンの反応と注目点 90万人超のフォロワーを持つインフルエンサーによる"リアルマネーでの実践記録"として大きな注目を集めた。特に以下の点が話題となっている。 透明性の高い情報開示 — 含み損のピーク時も含め、リアルタイムでの発信を継続 ナラティブ投資の典型例 — 宇宙・量子という「物語」に賭ける手法 個人投資家への影響力 — フォロワー数を考えると、言及した銘柄に対する注目度上昇は避けられない 免責事項 本記事は情報提供を目的としており、投資助言ではありません。宇宙・量子関連株は高いボラティリティを持ち、元本を大きく下回るリスクがあります。投資判断は自己責任でお願いします。

メルカリ（4385）の2026年通期決算が発表された。「古着を売るアプリ」として始まったメルカリが、今や決済・与信・海外展開まで手がける巨大リサイクル金融プラットフォームに変貌しつつある。本記事では、決算の主要数値・Fintech成長の実態・財務リスクの3点を投資家視点で読み解く。 主要財務ハイライト 指標 実績 前年比 売上収益 1,672億円 +16% コア営業利益 348億円 +74% 営業利益 345億円 +69% 純利益 194億円 +65% 売上の+16%成長よりも、利益の伸び率が圧倒的に高い。コア営業利益（株式報酬費用などを除いた調整後営業利益）が+74%というのは、「まだ成長フェーズ」と見なされていた会社が一気に利益体質へ転換してきた証拠だ。赤字ベンチャーと呼ばれた時期は完全に過去のものになった。 通期予想も上方修正され、売上2,200億円以上・コア営業利益400億円以上が射程圏内に。 国内Marketplace：「みんな売りすぎ・買いすぎ問題」が継続 国内MarketplaceのGMV（流通総額）は9,394億円（+11%）。1兆円の大台が見えてきた。 エンタメ・ホビー分野が好調。オタク層の財布がメルカリを支える構図 「家の不用品がまだまだ金になる」という命題は引き続き有効 ただし「売りすぎ・買いすぎ問題」（つまり過剰取引による品質低下）は継続課題 国内の出品・購入ユーザー数が増えるほどGMVが伸びる構造は安定しており、フライホイールが回り続けている。 Fintech事業：財布の中までメルカリ領土化 Fintech売上は+27%と高成長。メルカードとあと払い（BNPL）が牽引役だ。 メルカード（クレジットカード）の利用拡大 あと払いの浸透で「フリマの支払い→メルカリ金融」の導線が完成 債権残高3,281億円、+45%で急増。貸付ビジネスのスケールアップ 回収率99.4%という驚異的な数字。フリマ取引履歴を活用した与信モデルが機能している フリマで獲得した決済データ・評価データを与信に転用する発想は独自の競争優位性だ。銀行や消費者金融にはない「売買履歴という行動データ」が武器になっている。 米国事業：ついに黒字化 長年の課題だった米国事業が黒字に転じた。 US GMV：602百万ドル（+10%） USセグメント利益：11.8億円（前年は赤字） 海外への長年の投資がついてきた格好 「アメリカで燃やした金が少し帰ってきた」段階ではあるが、黒字化自体が一つのマイルストーン。今後の拡大ペースが焦点になる。 リスク：膨らむ債権と借入 業績は好調な一方、バランスシートは急拡大している。 資産：6,737億円 負債：5,532億円 Fintechが伸びるほど債権残高が増え、資金調達（借入）も増加 営業CF：マイナス192億円。債権増加で現金が一時的に吸われる構造 回収率99.4%は現時点では優秀だが、景気後退や信用リスクの高まりがあれば、この比率が崩れる可能性がある。便利さの裏で信用リスク管理に失敗すれば、財務が急速に悪化するシナリオは常に意識しておきたい。 配当は0円：「まず成長にポチる」スタンス 配当は今期も0円。株主還元より成長投資を優先する姿勢は一貫している。 Fintech拡大・海外展開・新事業への投資を継続するフェーズであり、キャッシュを社内に留めておく判断は合理的だ。長期保有派にとっては「成長の果実を複利で享受する」戦略になる。 まとめ：中古品アプリから金融インフラへ メルカリはもはや「フリマアプリ」ではない。決済・与信・海外マーケットプレイスを統合した「巨大リサイクル金融マシン」だ。 業績モメンタムは強く、Fintechの与信モデルは独自性が高い。一方で、Fintech拡大に伴う債権リスクと借入増加は、今後の最大の注目点になる。「フリマで客を集めて、金融で利益を盛り、米国黒字化まで決めたけど、次は貸した金をちゃんと回し続けられるか試される会社」——これがメルカリの現在地だ。 本記事は X（旧Twitter）の @kiokunir 氏による決算要約ツイートをもとに構成しています。

BASEが打ち出した「初期費用0円・月額0円」のECプラットフォームは、2012年当時の業界常識を覆すものだった。なぜそのモデルが可能だったのか。その背景にはリアルな現場課題を直視した、シンプルな逆張り戦略があった。 BASEの原点 — 「高すぎる」を解決する BASEの創業者・鶴岡裕太さんがネットショップ作成サービスを作ろうと思ったきっかけは、大分で洋品店を営む母親が「ネットショップを開きたい」と言ったことだった。しかし既存のEC構築サービスには初期費用数十万円・月額数万円の壁があり、個人商店には手が届かなかった。 ここで重要なのは、このきっかけが「崇高なビジョン」ではなく、身近な人の具体的な不満から始まっている点だ。 世界を変えたい → ❌ 革新的なSaaS → ❌ IPOしたい → ❌（少なくとも初期は） あったのは「非エンジニアでもECを作れるようにしたい」という、ごく素朴な動機だった。 「初期費用0円・月額0円」を可能にした逆張り 当時のEC構築市場の相場は、初期費用数十万円・月額数万円が当たり前だった。BASEが打ち出した「初期費用0円・月額0円」は、競合にとって信じがたいモデルだったはずだ。 BASEは商品が売れたときにのみサービス利用料（3%）と決済手数料（3.6%＋40円）が発生する収益モデルを採用した。「ユーザーが稼いだときだけ一緒に稼ぐ」という構造だ。 提供側はリスクを取ることになるが、ユーザーには「失敗してもタダ」という参入障壁の除去をもたらした。これが個人商店・スモビジへの一気の普及を後押しした。 受託→プロダクトという転換パターンの普遍性 「まず受託でキャッシュを稼ぎ、そこからプロダクトへ転換する」というパターンは、多くの日本のスタートアップが実践している。 チームラボ（2001年創業）: 初期はWebサイト制作などの受託開発を主力に据えながら事業基盤を固めた SmartHR: 前身のKUFUが「受託70%・自社サービス10%」という比率でスタートし、SaaSへと転換した 「まず受託でキャッシュを稼ぐ」という選択肢は、決して逃げではない。現場で繰り返す作業の中にこそ、プロダクトの種がある。 現場の「うんざり」は設計図になる スタートアップの教科書には「大きなビジョンを持て」と書いてある。しかし現実に強いプロダクトを作るのは、現場の「これ、なんとかならないか」という感覚だ。 自分の親が直面した不便、繰り返される問い合わせ、毎回同じ設定をゼロからやり直す徒労感——等身大の課題を解決するプロダクトは、ユーザーインタビューを重ねて作られた「仮説」とは別の強さを持つ。 あらゆる現場の「うんざり」は、プロダクトの設計図になりうる。 Source: X (Twitter) @RrrrrKayuy620