記事一覧

OpenClaw の創業者 Peter 氏が、次のバージョンで動画生成機能を正式搭載することを発表した。これにより、AI エージェントがテキストから動画生成までを一気通貫で完結できるようになる。 動画生成の対応プロバイダー 次バージョンでは、以下のプロバイダーが最初からサポートされる予定だ。 Alibaba BytePlus fal Google MiniMax OpenAI Qwen Together xAI 主要な動画生成 AI サービスをほぼ網羅しており、ユーザーはプロバイダーを選んでワークフロー内で動画を生成できるようになる。 これまでとこれからの違い この機能追加の意義は、ワークフローの断絶をなくすことにある。 これまで テキスト → 画像生成 → 外部ツールで動画化 外部ツールへの手動エクスポートが必要で、エージェントのフローが途切れていた。 これから テキスト指示 → AI エージェントが動画生成まで完結 エージェントが動画生成まで一手に担うことで、制作フローをエンド・ツー・エンドで自動化できる。 「もう 1 人の自分」から「チームそのもの」へ これまで OpenClaw は「もう 1 人の自分」として個人の作業を補助する位置づけだったが、動画生成の搭載によって**「チームそのもの」**として機能し始めていると言える。 テキスト生成・コード生成に加え、映像制作まで担当 複数の動画生成プロバイダーに対応することで、用途に応じた使い分けが可能 AIエージェントが「考える」だけでなく「制作する」領域まで拡張 まとめ OpenClaw への動画生成機能の追加は、AI エージェントの役割が「情報処理・生成支援」から「クリエイティブ制作」へと拡張する大きな転換点だ。9 つの主要プロバイダーへの対応により、動画コンテンツの制作フローを AI エージェント内で完結させられる可能性が開かれた。 正式リリース時には、具体的なプロンプト設計や各プロバイダーとの使い分けについても検証していきたい。 情報ソース: @ichiaimarketer のポスト（2026-04-07） 元ツイートを見る

Claude Code を使い続けると、トークン消費が思いのほか速く、使用制限に達してしまうことがある。その主な原因のひとつが、ターミナルコマンドの出力だ。git status や npm install が吐き出すプログレスバー・警告・ログといったノイズが、そのままコンテキストに流れ込んでいる。 この問題を解決するツールが RTK（Rust Token Killer） だ。 RTK とは RTK は Claude Code とターミナルの間に挟む「CLI プロキシ」ツール。Rust 製の単一バイナリで、依存関係ゼロのオープンソースプロジェクトだ。 GitHub: rtk-ai/rtk 公式サイト: https://www.rtk-ai.app/ コマンドを透過的にラップして出力をフィルタリングし、LLM のコンテキストに送る情報量を大幅に削減する。実測で 60〜90% のトークン削減、1,000 万トークン以上の削減（89% 削減）を達成した事例も報告されている。 4 つの最適化戦略 RTK は以下の戦略でターミナル出力を圧縮する: 戦略 内容 スマートフィルタリング ANSI エスケープコード、スピナー、プログレスバーを除去 グルーピング 関連する出力をまとめて集約 重複除去 繰り返しパターンを排除 トランケーション エラーは保持しつつ、冗長な成功出力を切り詰め オーバーヘッドは 1 コマンドあたり 10ms 未満で、100 以上の開発コマンドに対応している。 セットアップ 1 rtk init -g -g フラグでグローバルインストール。Claude Code / GitHub Copilot との統合も自動で設定される。 インストール後、RTK はコマンドを透過的に書き換える。たとえば git status は内部で rtk git status として実行され、Claude には圧縮済みの出力が渡される。ユーザーが意識する必要はない。 ...

前回の記事で EDINET の XBRL データを Python で扱う方法を紹介した。今回は、その仕組みを活用して構築されている企業分析サービス「バフェット・コード」を分析し、何ができるのかを網羅的にまとめる。 バフェット・コードとは バフェット・コードは、EDINET（有価証券報告書）と TDNET（適時開示）の XBRL データをパースし、企業の財務情報をワンストップで分析できる SaaS サービスだ。バフェットコード株式会社が開発・運営している。 データパイプラインの流れは以下の通り: EDINET / TDNET から XBRL ファイルを取得 XBRL をパースして RDB に格納 過去データと株価を組み合わせて財務指標を算出 スクリーニング・比較用のデータセットを更新 このパイプラインの XBRL パース部分に、前回紹介した edinet_xbrl ライブラリが使われている。 Web アプリケーションでできること バフェット・コードの Web アプリ（buffett-code.com）では以下の機能が利用できる。 企業分析 財務データの閲覧: B/S（貸借対照表）、P/L（損益計算書）、C/S（キャッシュフロー計算書）を一覧表示 企業概況: 設立日、上場日、事業内容などの基本情報 役員一覧: 取締役・監査役の情報 大株主情報: 四半期ごとの大株主構成 セグメント情報: 事業セグメント別の業績データ 類似企業の表示: 同業他社の自動提案 スクリーニング・比較 条件検索: 財務指標（PER、PBR、ROE 等）でフィルタリング 企業比較: 複数企業の財務データを横並びで比較 株主検索: 特定の株主が保有する企業を検索 資料検索 横断検索: EDINET・TDNET の資料に加え、各社の決算説明資料や統合報告書も横断的に検索 CSV ダウンロード: 年間業績や各種指標のダウンロード Web API でできること バフェット・コードは REST API（v4）を提供しており、プログラムから財務データにアクセスできる。API の利用には有償契約が必要だが、テスト用 API キーも用意されている。 ...

『会社四季報』の【財務】欄は、企業の安全性や収益性を見極めるための重要なセクションです。この記事では、三菱UFJ eスマート証券（旧 auカブコム証券）の「カブヨム」に掲載された四季報編集部による解説をもとに、財務欄から安心な投資先を探すための7つのポイントを整理します。 財務欄に載っている8つの数字 四季報の【財務】欄には以下の項目が掲載されています。 ROE（自己資本利益率） ROA（総資産利益率） 総資産 自己資本 自己資本比率 資本金 利益剰余金 有利子負債 これらの数字を組み合わせて読むことで、企業の「安全性」「収益性」「成長性」を多角的に評価できます。 ポイント1: 総資産で会社の規模を把握する 総資産は、会社の事業を行うための諸要素を合計したもので、貸借対照表（BS）の左側に記載されます。ただし、総資産が大きい＝良い会社とは限りません。 総資産の増加が積極投資によるものなら前向き 有利子負債の増加が主因なら安全性の懸念 投資後の利益率が低下すれば収益性は悪化 総資産の増減を見る際は、ROA や自己資本比率とセットで確認しましょう。 ポイント2: 自己資本比率で安全性を測る 自己資本比率は、総資産に対する自己資本の割合です。 高い → 返済不要な資金の比率が大きく、財務的に安定 低い → 借入金への依存度が高く、景気悪化時にリスク ただし、自己資本比率が高すぎると ROE が低下する「安全性と効率性のトレードオフ」が存在します。業種ごとの平均値と比較して判断するのがポイントです。 ポイント3: ROE で稼ぐ力を見る ROE（自己資本利益率）は、純利益を自己資本で割った指標です。 1 ROE = 純利益 ÷ 自己資本 純利益が同額なら、自己資本が少ない会社ほど ROE は高くなる ROE が高い＝優れた企業とは限らない（過度な借入で自己資本が小さいケースもある） 自己資本比率とセットで評価するのが重要 東証が求める「資本コストや株価を意識した経営」の流れの中で、ROE は特に注目される指標です。 ポイント4: 利益剰余金の蓄積をチェックする 利益剰余金は、毎年の純利益から配当金を差し引いた残りの累計です。 プラスで増加傾向 → 着実に利益を積み上げている マイナスに転落 → 過去の累積赤字が大きい状態 利益剰余金 ≠ 現預金（設備投資等に回されている） 利益剰余金がマイナスに膨らむと、自己資本そのものがマイナスとなる「債務超過」に陥ります。 ...

2026年、「1人で100億稼ぐ企業」が大量発生するという予測が現実味を帯びてきた。すでに海外では1人で30億円規模の売上を達成した事例も登場している。AI が業務を圧縮し続ける今、「大人数＝強い会社」という常識が根本から覆されつつある。 Obsidian が示す新しいモデル ノートアプリとして世界中のナレッジワーカーに愛用されている Obsidian は、わずか 9人のチームで運営されており、エンジニアは 3人 のみ。さらに 9人目のチームメンバーは “Sandy” という猫だ。 それでも Obsidian の1人あたり売上は、Apple や Google を大きく上回る水準にあると言われている。この数字が示すのは、規模ではなく密度が競争力を左右するという現実だ。 「才能密度」が企業の強さを決める これまでの組織論では、人数を増やすことが成長の証であり、大企業が有利とされてきた。しかし AI が以下のような業務を自動化・圧縮できるようになった今、その前提が崩れている。 ルーティンのコーディング・テスト作業 ドキュメント生成・翻訳・要約 カスタマーサポートの一次対応 マーケティングコンテンツの初稿作成 データ集計・レポート作成 結果として、少人数の高スキル人材が AI をフル活用することで、かつては数十人を要した仕事を完結させられるようになった。重要なのは「何人いるか」ではなく、「才能の密度（Talent Density）」 だ。 無駄を削ることで生まれる速度 Obsidian が象徴するような高効率企業には、共通する特徴がある。 全社 MTG なし — 意思決定コストを最小化 評価制度の簡素化 — 時間を消耗するプロセスを廃止 小さなチームへの強い信頼 — 自律性と責任が同時に与えられる これらは単なるコスト削減ではなく、スピードを生むための構造設計だ。 2026年：一人会社・極小チームが台頭する年 AI ツールの進化により、2026年はソロファウンダーや極小チームが本格的に大企業と競合できる年になると見られている。 SaaS プロダクト: コーディング・インフラ管理を AI が補助 コンテンツビジネス: 調査・執筆・SEO 対策を AI が効率化 コンサルティング: レポート作成・分析を AI が加速 単に「AI を使う」のではなく、「AI で何を削れるか」を徹底的に考える組織が次の覇者になる可能性が高い。 まとめ 旧来の成功モデル 新しい成功モデル 大人数 = 強い 才能密度 = 強い 多くの管理職 フラットな自律組織 プロセス重視 スピード・結果重視 人手でスケール AI でスケール 「1人で100億」はもはや夢物語ではない。AI が業務を圧縮し、才能密度の高い少人数チームが巨大企業の生産性を上回る——そんな時代がすでに始まっている。 ...

Claude Code を使っていて「なんかコストかかるな…」と思ったことはないでしょうか。以前、デフォルト設定のまま使い続けると推定 2 億 6,400 万トークンもの無駄が発生するという事例が話題になりました。 その後 Claude Code 自体が大幅に改善されましたが、トークン消費を意識した使い方は今でも重要です。本記事では、現在のバージョン（2026年4月時点）で有効な最適化ポイントを整理します。 ツール検索の遅延ロード（Deferred Tools） 以前の Claude Code では、すべてのツール定義がセッション開始時にコンテキストに読み込まれ、大量のトークンを消費していました。ENABLE_TOOL_SEARCH を明示設定することで改善できるという報告もありました。 現在のバージョンでは、この問題はビルトインで解決されています。 ツール定義は「遅延ロード（Deferred Tools）」方式に変わり、ツール名だけがコンテキストに載り、実際のスキーマは必要になった時点で初めてロードされます。ENABLE_TOOL_SEARCH を手動で設定する必要はありません。 プロンプトキャッシュの 5 分 TTL — 今も最大の落とし穴 Claude のプロンプトキャッシュは 5 分で期限切れになる。これは現在も変わっておらず、トークンコストに最も影響する要素だ。 5 分休憩しただけで、会話全体が再処理され、コストが 10 倍以上に跳ね上がることがある。 つまり: 長時間セッションの途中で離席する ちょっと休憩してから作業再開する 別の作業をしてから Claude Code に戻ってくる といった行動がすべて、想定外のコスト増につながる。「休憩明けの最初のメッセージが一番高い」というのは、このキャッシュ再処理が原因だ。 キャッシュを意識した作業フロー 5 分以内に次の操作を行う — キャッシュが維持される 長い離席の前にセッションを終了する — 戻ってきたら /resume で再開した方が、コンテキストが圧縮されて効率的 タスクの区切りで /compact を実行する — 手動でコンテキストを圧縮し、次のキャッシュミス時のコストを下げる コンテキスト自動圧縮を活かす Claude Code はコンテキストウィンドウの上限に近づくと、過去の会話を自動的に圧縮する。この仕組みのおかげで、長時間セッションでも会話が途切れることはない。 ただし、圧縮時にはトークンが消費される。不要にコンテキストを膨らませないことが、結果的にコスト削減になる。 コンテキストを膨らませない工夫 やりがちなこと 改善策 大きなファイルを全行読む 必要な範囲だけ offset / limit 指定で読む ビルドログをそのまま流す エラー時だけ出力を確認する 試行錯誤を同一セッションで続ける 方針が変わったら新しいセッションで仕切り直す CLAUDE.md に大量の指示を詰め込む 必要最小限に保つ（毎ターンのコンテキストに載る） 現在のビルトイン最適化機能 2026年4月時点で Claude Code に組み込まれている主なトークン最適化機能: ...

EDINETで公開されている有価証券報告書のXBRLファイルを、Pythonで効率的にパース・活用する方法を紹介する。edinet-xbrl ライブラリを使えば、複雑なXBRL仕様を意識せずにデータを抽出できる。 EDINETとXBRLとは EDINET（Electronic Disclosure for Investors’ NETwork）は、金融商品取引法に基づく有価証券報告書等の開示書類を電子的に提出・閲覧するためのシステムだ。金融庁が運営しており、上場企業の決算書データをXBRL形式でダウンロードできる。 XBRL（eXtensible Business Reporting Language）は、財務・経営・投資情報を標準化されたXMLベースで記述するための言語だ。構造化されたデータとしてマシンリーダブルだが、仕様が複雑で、そのまま扱うのは難易度が高い。 edinet-xbrl ライブラリ BuffettCode/edinet_xbrl は、EDINETのXBRLファイルをPythonオブジェクトとして扱えるようにするライブラリだ。 インストール 1 pip install edinet-xbrl 基本的な使い方 1 2 3 4 5 6 7 8 9 10 11 12 13 from edinet_xbrl.edinet_xbrl_parser import EdinetXbrlParser # パーサーの初期化 parser = EdinetXbrlParser() # XBRLファイルをパースしてデータコンテナを取得 xbrl_file_path = "path/to/your/xbrl/file.xbrl" edinet_xbrl_object = parser.parse_file(xbrl_file_path) # 例: 該当年度の総資産を取得 key = "jppfs_cor:Assets" context_ref = "CurrentYearInstant" current_year_assets = edinet_xbrl_object.get_data_by_context_ref(key, context_ref).get_value() key と context_ref の特定 XBRLでは、取得したいデータ項目を key（タクソノミ要素 = データ項目の識別子）と context_ref（コンテキスト参照 = 期間や連結/単体などの条件）の組み合わせで指定する。jppfs_cor は日本GAAP財務諸表のタクソノミ名前空間だ。これらを特定するには： ...

JWT 認証ライブラリ fast-jwt に重大な脆弱性が発見された。公開鍵の先頭に空白文字や改行があるだけで認証が突破される可能性があり、影響はバージョン 6.1.0 以下に及ぶ。 fast-jwt とは fast-jwt は Node.js 向けの高速な JWT（JSON Web Token）の署名・検証ライブラリ。パフォーマンスを重視した実装で広く利用されているが、今回その内部の文字列処理と正規表現の甘さが致命的な脆弱性につながった。 CVE-2026-34950: 空白文字による認証バイパス 問題の概要 CVSS スコア 9.1（Critical） の深刻な脆弱性。公開鍵の検証に使われている正規表現が、文字列の先頭を厳密に検証していないという欠陥に起因する。 攻撃メカニズム 公開鍵の先頭にスペースや改行文字（\n）が含まれると、正規表現による公開鍵の検証が失敗する。その結果、公開鍵が HMAC 用の秘密鍵として誤って扱われ、攻撃者は任意のトークンを署名できてしまう。 1 2 3 4 5 6 7 8 9 // 通常の公開鍵（検証成功） -----BEGIN PUBLIC KEY----- ... -----END PUBLIC KEY----- // 先頭に空白が入った場合（検証失敗 → HMAC 鍵として扱われる） -----BEGIN PUBLIC KEY----- ... -----END PUBLIC KEY----- これは過去に修正されたはずの CVE-2023-48223（アルゴリズム混同攻撃）と同様の攻撃を再び可能にする。前回の修正が不完全だったことが根本原因だ。 ...

Google の Gemma 4 31B モデルをベースに、安全性制限を除去した「Gemma-4-31B-JANG_4M-CRACK」が Hugging Face で公開された。開発元の dealignai は、Abliteration（アブリテレーション）と呼ばれる手法でモデルの拒否行動を除去した。知識性能の劣化は MMLU で -2.0% にとどまる。 Abliteration とは何か Abliteration は、LLM の学習済み拒否メカニズムを再学習なしで除去する手法だ。2024年頃から研究が進み、現在では複数のバリエーションが存在する。 基本的な仕組みは以下の通り: 拒否方向の特定: 有害なプロンプトと無害なプロンプトをモデルに入力し、残差ストリーム（Transformer 内部の中間表現が流れる経路）の活性化を記録する。両者の平均差分ベクトルが「拒否方向」（refusal direction）となる 重み直交化: 特定した拒否方向に対してモデルの重み行列を直交化（orthogonalization）する。直感的には、拒否方向の成分を重みから差し引く操作にあたる。これにより、モデルはその方向への活性化を生成できなくなる 性能保持: 拒否方向のみをターゲットにするため、モデルの汎用的な知識や推論能力への影響は最小限に抑えられる 最近の改良版である Norm-Preserving Biprojected Abliteration では、ベクトルのノルムを保持しながら除去を行うことで、さらに性能劣化を抑えている。 CRACK モデルのスペック 項目 値 ベースモデル google/gemma-4-31b-it アーキテクチャ Dense Transformer + Hybrid Sliding/Global Attention 量子化プロファイル JANG_4M（CRITICAL=8-bit, COMPRESS=4-bit） 平均ビット数 5.1 bits モデルサイズ 18 GB ビジョン マルチモーダル対応（ビジョンエンコーダは量子化せず float16 を維持） フォーマット JANG v2（MLX ネイティブ safetensors） JANG_4M のビット割り当て JANG プロファイルの特徴は、アテンション層とMLP層で異なるビット精度を割り当てる点にある: CRITICAL（8-bit）: Attention の Q/K/V/O 重み、エンベディング COMPRESS（4-bit）: MLP の gate/up/down projection、その他の重み Dense モデルは MLP 部分の量子化耐性が高いため、この戦略により 18GB という実用的なサイズを実現している。 ...

API課金なしで、ローカル環境にAIエージェントを無制限で運用できるセットアップ方法を紹介します。OpenClaw（エージェントインターフェース）+ Ollama（ローカルモデルサーバー）+ Gemma4（推論エンジン）の組み合わせにより、Telegram・Discord・LINEなどの既存チャンネルともシームレスに連携できます。 構成概要 コンポーネント 役割 OpenClaw AIエージェントのインターフェース・オーケストレーション Ollama ローカルLLMサーバー（モデルの管理・API提供） Gemma4 推論エンジン（Google製オープンモデル） この3つを組み合わせることで、クラウドAPIへの依存なしにフル機能のAIエージェントが動作します。 セットアップ手順 1. Ollama のインストール 1 2 3 4 5 # macOS / Linux curl -fsSL https://ollama.ai/install.sh | sh # Windows # https://ollama.ai から インストーラーをダウンロード 2. Gemma4 モデルの取得 1 ollama pull gemma4 3. OpenClaw のインストール 1 npm install -g openclaw 4. オンボーディングウィザードの実行 1 openclaw onboard ウィザードに従ってOllama接続設定とチャンネル連携（Telegram・Discord・LINEなど）を行います。 ...