オープンソース on KnightLiブログ

DeepSeek 4 をローカルで動かす：Apple Silicon Mac における Antirez ds4 の試み

Mon, 11 May 2026 08:51:37 +0800

Antirez が新しいプロジェクト ds4 をオープンソース化しました。これは汎用 LLM フレームワークではなく、DeepSeek V4 Flash 向けのローカル推論エンジンで、Apple Silicon と Metal バックエンドに重点を置いています。

プロジェクト URL：https://github.com/antirez/ds4

ds4 とは

ds4 の目的は明確です。Mac 上で DeepSeek V4 Flash をローカル実行することです。

現在は、次の 3 つの使い方が用意されています。

対話型 CLI。
HTTP server。
実験的な Agent モード。

位置づけとしては、llama.cpp、Ollama、vLLM のような汎用ツールを置き換えるものではなく、特定のモデルに深く最適化した推論プロジェクトに近いものです。

なぜ注目に値するのか

この種のプロジェクトが注目に値する理由は主に 3 つあります。

第一に、作者が Redis の作者である Antirez であることです。彼は長く低レイヤーのシステム、性能、シンプルなツールに関心を持っており、プロジェクトの作風も比較的ストレートです。

第二に、DeepSeek V4 Flash は効率的な推論を指向するモデルです。ローカル実行の体験が十分によければ、Mac ユーザーにとってかなり魅力的です。

第三に、ds4 は Apple Metal を直接ターゲットにしています。最初にあらゆるプラットフォームをサポートしてから徐々に最適化する路線ではなく、明確な 1 つの場面を深く掘るプロジェクトに見えます。

誰に向いているか

ds4 は、次のようなユーザーに向いています。

Apple Silicon Mac を使っている。
DeepSeek V4 Flash をローカルで動かしたい。
Metal 推論性能に関心がある。
alpha 段階のプロジェクトを試すことに抵抗がない。
軽量な推論エンジンやモデル実行の細部を調べたい。

安定したデプロイ、クロスプラットフォーム実行、OpenAI API 互換のエコシステムが目的なら、現時点では第一候補ではないかもしれません。実験用ツール、または技術的な観察対象として見るのがよさそうです。

使い方

プロジェクト README にある基本的な流れは、まずビルドしてから実行するというものです。

1
2
3

git clone https://github.com/antirez/ds4.git
cd ds4
make

対話的に実行する場合：

./ds4

HTTP server を起動する場合：

`1`	`./ds4 --server`

Agent モード：

`1`	`./ds4 --agent`

具体的なパラメータやモデルファイルの準備方法は、プロジェクトがまだ速いペースで変化しているため、リポジトリの README を確認するのが確実です。

現時点のリスク

ds4 はまだ初期段階のプロジェクトなので、使う前に次の点を想定しておく必要があります。

機能が完全ではない可能性があります。
パラメータ、モデル形式、コマンドラインの挙動が変わる可能性があります。
互換性は主に Apple Silicon と Metal を中心にしています。
Agent モードは実験的な性格が強く、本番フローに直接使うには向いていません。
問題が起きた場合、自分で README、issue、ソースコードを読んで調べる必要があります。

つまり、現時点では一般ユーザー向けのワンクリックツールというより、試してみる価値のあるオープンソース実験です。

汎用推論ツールとの違い

汎用推論ツールは通常、モデル形式、プラットフォーム、バックエンド、API の広い互換性を目指します。ds4 の方向性はもっと狭く、DeepSeek V4 Flash と Metal によるローカル実行に絞られています。

この選択には利点と代償があります。

利点は、実装を集中させやすく、性能や体験を単一の目標に合わせて最適化しやすいことです。代償は、適用範囲が限られることです。さまざまなモデルを動かすための道具ではなく、完全なデプロイ基盤の置き換えにも向いていません。

すでに llama.cpp や Ollama を使っているなら、ds4 は既存のワークフローをすぐ置き換えるものではなく、補助的なテストツールとして見るのが自然です。

まとめ

ds4 の見どころは、「また 1 つローカル大規模モデルツールが増えた」ことではありません。DeepSeek V4 Flash、Apple Silicon、Metal、ローカル推論という狭い範囲に絞っている点です。

手元に適した Mac があり、初期段階のプロジェクトを触ることに抵抗がないなら、今後の性能、モデル対応の方法、server/agent 機能の進化を追う価値があります。本番環境については、インターフェイスと使い方が安定してから評価するのがよいでしょう。

参考

GitHub プロジェクト：https://github.com/antirez/ds4

Pixelle-Video：1つのテーマから短尺動画を生成するオープンソース AI エンジン

Thu, 07 May 2026 20:25:17 +0800

Pixelle-Video は、AIDC-AI が公開している全自動短尺動画生成エンジンです。目標は明快です。ユーザーがテーマを入力すると、動画台本、AI 画像または動画、音声ナレーション、BGM、最終合成までを自動で処理します。

この種のツールは、短尺動画の量産、知識解説、口播コンテンツ、小説解説、歴史・文化系動画、自媒体向け素材実験に向いています。単体の「テキストから動画」モデルではなく、複数の AI 能力をつなげた制作パイプラインです。

自動化できること

Pixelle-Video の標準フローは次のように整理できます。

テーマまたは固定台本を入力する。
大規模言語モデルでナレーション原稿を生成する。
シーン設計に沿って画像または動画素材を生成する。
TTS で音声ナレーションを生成する。
BGM を追加する。
動画テンプレートを適用して最終動画を合成する。

README では「台本生成 → 画像計画 → フレームごとの処理 → 動画合成」という流れとして説明されています。モジュール化されているため、各ステップのモデルやパラメータを差し替えたり、独自ワークフローに変更したりしやすい構成です。

主な機能

プロジェクトが対応している機能はかなり幅広いです。

AI 台本生成：テーマから動画ナレーションを自動生成。
AI 画像生成：各セリフや各シーンに対応するイラストを生成。
AI 動画生成：WAN 2.1 などの動画生成モデルに対応。
TTS 音声：Edge-TTS、Index-TTS などをサポート。
BGM：内蔵 BGM またはカスタム音楽を利用可能。
複数サイズ出力：縦動画、横動画など複数の比率に対応。
複数モデル：GPT、Qwen、DeepSeek、Ollama などに対応。
ComfyUI ワークフロー：標準ワークフローを使うことも、画像生成、TTS、動画生成などを差し替えることも可能。

最近の更新では、モーション転写、デジタルヒューマン口播、画像から動画、多言語 TTS ボイス、RunningHub 対応、Windows 一体型パッケージなども追加されています。単なるスクリプトではなく、より完成度の高い制作ツールへ向かっていることが分かります。

インストールと起動

Windows ユーザーは、まず公式の一体型パッケージを見るのがよいでしょう。Python、uv、ffmpeg を手動で準備せずに使えるようにするためのもので、展開後に start.bat を実行し、ブラウザで Web UI を開いて API と画像生成サービスを設定します。

ソースコードから起動する場合、README では次の基本手順が示されています。

1
2
3

git clone https://github.com/AIDC-AI/Pixelle-Video.git
cd Pixelle-Video
uv run streamlit run web/app.py

ソースからの利用は macOS、Linux ユーザーや、テンプレート、ワークフロー、サービス設定を変更したい人に向いています。主な前提は uv と ffmpeg です。

設定の要点

初回利用時に重要なのは、すぐに「生成」を押すことではなく、外部能力を正しく接続することです。

LLM 設定は台本品質を左右します。Qwen、GPT、DeepSeek、Ollama などを選び、API Key、Base URL、モデル名を入力します。コストを抑えたいならローカルの Ollama が候補になります。安定した結果を優先するなら、クラウドモデルの方が扱いやすいことが多いです。

画像・動画生成設定は画面品質を決めます。プロジェクトはローカル ComfyUI と RunningHub に対応しています。ComfyUI に慣れているユーザーなら、自分のワークフローを workflows/ ディレクトリに置き、標準の画像生成、動画生成、TTS フローを差し替えられます。

テンプレート設定は最終動画の見た目を決めます。プロジェクトは templates/ ディレクトリで動画テンプレートを管理し、静的テンプレート、画像テンプレート、動画テンプレートを命名規則で分けています。クリエイターにとっては、素材だけでなく、そのままプレビューしてダウンロードできる動画まで出せる点が実用的です。

向いている人

Pixelle-Video は次のような人に向いています。

短尺動画クリエイター：企画を素早く投稿可能な下書き動画にしたい人。
AIGC ツールユーザー：LLM、ComfyUI、TTS、動画合成をつなげたい人。
開発者・自動化ユーザー：オープンソースを基にテンプレートやワークフローを改造し、自分の素材やモデルを接続したい人。

高品質な一本ものの動画を作るだけなら、手作業の編集を完全に置き換えるとは限りません。ただし、同じ構造の解説動画、口播動画、科普系コンテンツを大量に作りたいなら、このパイプライン型の考え方はかなり有用です。

注意点

この種のツールの上限は複数の工程で決まります。台本モデルが弱いと内容が薄くなり、画像モデルが弱いと画面が散らかり、TTS が不自然だと動画が粗く感じられます。テンプレートが合わなければ、最終的な見栄えも弱くなります。

そのため、まずは「60秒の縦型知識解説動画」のような固定シーンから調整するのがおすすめです。LLM、画風、TTS 音色、BGM、テンプレートを固めてから、ほかのテーマへ広げる方が安定します。

また、ローカル無料構成にも対応していますが、通常は GPU、ComfyUI 設定、モデルファイルが必要です。ローカル推論環境がない場合は、クラウド LLM と RunningHub を組み合わせると導入は楽になりますが、利用コストには注意が必要です。

短評

Pixelle-Video の見どころは「一文から動画を生成できる」ことだけではありません。短尺動画制作を、台本、映像、音声、音楽、テンプレート、合成という交換可能なモジュールに分解している点にあります。一般ユーザーにとっては低ハードルの AI 動画ツールであり、開発者にとっては改造しやすい短尺動画自動化フレームワークです。

AI 短尺動画パイプラインを研究している人、あるいは ComfyUI、TTS、LLM、テンプレート合成を一つの製品としてつなげたい人なら、Pixelle-Video は試して分解してみる価値があります。

Warp オープンソース化：ターミナルから Agentic Development Environment へ

Thu, 07 May 2026 20:15:08 +0800

warpdotdev/warp は Warp のオープンソースクライアントリポジトリです。Warp は現在、自身を「ターミナルから生まれた agentic development environment」と位置付けています。つまり、ターミナルを土台にしながら、AI coding agent、コードベース索引、タスク管理、開発ワークフローを同じ環境に統合しようとしています。

これは普通のターミナルエミュレータのオープンソースリポジトリではありません。むしろ、Claude Code、Codex、Gemini CLI のような agent が一般化する中で、ターミナル自体が agent を調整し、観察し、管理する開発環境になるべきか、という問いへの答えに近いものです。

Warp の答えは「なるべき」です。

現在のリポジトリ状況

2026年5月7日時点で、warpdotdev/warp は公開リポジトリで、GitHub では約 56k stars、4.1k forks が表示されています。README では、Warp のクライアントコードがオープンソース化され、コミュニティからの貢献を歓迎すると説明されています。

主要言語は Rust です。GitHub の言語統計では Rust が 98% 以上を占めています。これは Warp の位置付けと合っています。Web のラッパーではなく、クロスプラットフォームのネイティブ開発ツールです。

README で重要な点は次の通りです。

Warp は agentic development environment, born out of the terminal。
内蔵 coding agent を使えるだけでなく、Claude Code、Codex、Gemini CLI などの外部 CLI agent にも接続できる。
OpenAI は新しくオープンソース化された Warp リポジトリの founding sponsor。
リポジトリ内の agentic management workflows は GPT models によって駆動される。
Warp UI framework 関連 crate は MIT license、それ以外のコードは AGPL v3。

これらを見ると、Warp のオープンソース化は単にターミナルを公開しただけではなく、agent ワークフローの実験場として運営していることが分かります。

Warp は単なるターミナルではない

従来のターミナルが主に解決していたのは次の三つです。

shell を起動する。
コマンドを実行する。
出力を表示する。

初期の Warp の差別化は、ターミナルをより現代的にすることでした。コマンドブロック、補完、履歴、コラボレーション、UI 的な操作、クロスプラットフォーム体験などです。現在はさらに進み、AI agent を中心に開発フローを組み立てようとしています。

README から見ると、Warp はもはや「より使いやすい terminal」だけを強調していません。次の要素を重視しています。

内蔵 coding agent。
外部 CLI agent 対応。
issue triage。
spec 作成。
PR review。
contributor coordination。
観察可能な agent sessions。

つまり Warp は、ターミナルを「コマンドを入力する場所」から「複数の agent と一緒に働く場所」へ変えようとしています。

Oz とオープンソース管理

README では Oz が何度も登場します。

Warp の contribution overview では、多数の Oz agents が issue triage、spec 作成、実装、PR review に取り組んでいる様子が示されています。これは興味深い設計です。AI agent を「個人のコード作成支援」から「オープンソース協作の管理支援」へ広げているからです。

従来のオープンソースプロジェクトで難しいのは、コードを書くことだけではありません。むしろ維持管理です。

issue が多すぎて分類されない。
bug と feature request が混在する。
新規貢献者が取り組みやすいタスクを見つけにくい。
PR review の負担が大きい。
メンテナーがコミュニティ議論を継続的に追いにくい。

Warp の考え方は、agent にプロジェクト管理と協作作業の一部を先に担わせることです。README には Oz for OSS も登場します。これはメンテナー向けのプログラムで、同様の agentic open-source management workflows をほかのリポジトリへ持ち込むためのものです。

つまり Warp の狙いはターミナル製品だけではなく、AI 時代のオープンソース維持管理モデルの探索にもあります。

リポジトリ構成と技術スタック

リポジトリ構成を見ると、Warp は大規模な Rust プロジェクトです。

ルートには次のようなものがあります。

app/：メインアプリケーション関連コード。
crates/：中核 Rust crates。
assets/：リソースファイル。
command-signatures-v2/：コマンドシグネチャ関連。
docker/、script/、resources/、specs/ などのエンジニアリング用ディレクトリ。
.claude/、.warp/、.agents/skills などの agent 関連設定。

WARP.md にはより詳しいエンジニアリング説明があります。Warp は Rust-based terminal emulator で、自社製 UI framework WarpUI を使っていると説明されています。

主要モジュールはおおよそ次のように理解できます。

app/：ターミナルエミュレーション、shell 管理、AI 統合、Drive、認証、設定、workspace、session。
crates/warp_core/：中核ユーティリティとプラットフォーム抽象。
crates/editor/：テキスト編集機能。
crates/warpui/ と crates/warpui_core/：自社製 UI framework。
crates/ipc/：プロセス間通信。
crates/graphql/：GraphQL client と schema。

WARP.md ではさらに次のような特徴も挙げられています。

Entity-Handle system。
モジュール化された workspace 構造。
macOS、Windows、Linux クロスプラットフォーム、および WASM target。
Agent Mode、文脈認識、コードベース索引を含む AI integration。
Warp Drive クラウド同期。

この複雑さは、従来の軽量 terminal よりも、ほぼ完全な IDE に近いものです。

ローカルビルド

README のローカルビルド手順は簡潔です。

1
2
3

./script/bootstrap
./script/run
./script/presubmit

それぞれ次の役割です。

./script/bootstrap：プラットフォーム別の初期化。
./script/run：Warp をビルドして実行。
./script/presubmit：フォーマット、clippy、テストなどの提出前チェック。

WARP.md にはさらに細かいコマンドもあります。

cargo run
cargo bundle --bin warp
cargo nextest run --no-fail-fast --workspace --exclude command-signatures-v2
cargo fmt
cargo clippy --workspace --all-targets --all-features --tests -- -D warnings

Warp にコードを貢献するなら、./script/presubmit は基本的に必須です。

貢献フロー

Warp の貢献フローは、単に「PR を出せばよい」ではありません。

README では issue から PR までの軽量な流れが説明されています。

まず既存 issue を検索する。
重複がなければ bug または feature request を提出する。
メンテナーが issue を review し、readiness label を付けることがある。
ready-to-spec は、設計を spec として展開できる状態。
ready-to-implement は、設計が比較的明確で実装 PR に進める状態。
貢献者はラベル付き issue を引き受けられる。

この流れは大規模オープンソースに向いています。「アイデア」「設計」「実装」を分けることで、貢献者が最初から違う方向へ実装してしまうリスクを減らせます。

AI agent にも相性が良い流れです。agent はまず issue を整理し、spec を書き、テストを追加してから実装に進めます。Warp 自身もこの方式で agentic project management を示しています。

ライセンス：MIT + AGPL v3

Warp は二つのライセンス構成を採っています。

README では次のように説明されています。

Warp UI framework、つまり warpui_core と warpui crates は MIT license。
リポジトリのそれ以外のコードは AGPL v3。

これは重要です。AGPL v3 はネットワークサービスや配布に対して、より強いオープンソース要件を持ちます。学習、研究、貢献であれば大きな問題はありませんが、Warp のコードを商用製品やクローズドソース派生物に使いたい場合は、license を慎重に読み、必要なら法務相談が必要です。

簡単に言えば、Warp はオープンソースですが、「自由に持っていって閉源商用化できる」タイプの緩いライセンスではありません。

注目すべき点

第一に、Warp はターミナル、agent、プロジェクト管理を一つにまとめようとしています。

多くの AI coding ツールはまだ CLI かエディタプラグインです。Warp はターミナルという入口から、agent タスク、コード実行、コマンド出力、PR ワークフロー、チーム協作を統合しようとしています。

第二に、Warp のオープンソース化は agent ワークフロー観察に向いています。

コードを公開するだけでなく、contribution overview、agent session、issue triage、spec フローも見せています。AI がオープンソース協作にどう参加できるかを研究したい人にとって、このリポジトリ自体がサンプルです。

第三に、Warp は複雑な Rust デスクトップアプリケーションです。

Rust GUI、ターミナルエミュレータ、クロスプラットフォームアプリ、GraphQL client、クラウド同期、AI 統合を学びたいなら、読むべき構造が多くあります。ただし小さなプロジェクトではないため、新規貢献者はまずドキュメントと issue フローを読むべきです。

第四に、Warp は「内蔵 agent」と「bring your own CLI agent」の両方を支援しています。

これは現実的です。開発者が一つの agent だけを使うとは限りません。Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw などは共存し続けるでしょう。Warp がそれらの作業台になれるなら、単一目的のターミナル以上の価値があります。

誰が注目すべきか

通常のターミナルユーザーにとって、Warp に注目する意味は、ターミナルがコマンドラインツールから AI ワークベンチへ変わりつつあるかもしれない点です。

AI coding agent をよく使う人にとって、Warp は複数 agent を管理しようとしている点で注目に値します。単なるチャット入口ではありません。

オープンソースメンテナーなら、Oz for OSS の流れを見る価値があります。agent による issue triage、PR review、コミュニティ協作、貢献者案内を試みています。

Rust 開発者にとって、Warp は大型の実例デスクトップアプリです。UI、ターミナル、クラウド同期、AI 統合、クロスプラットフォームコードの構成を研究できます。

単に従来のターミナルをすぐ置き換えたいだけなら、まず正式版をダウンロードして使い、その後でソースを読むか決めるのがよいでしょう。ソースから直接ビルドするのは、貢献者や深いユーザー向けです。

短評

Warp のオープンソース化の要点は、「現代的なターミナルがオープンソースになった」だけではありません。

より正確には、Warp はターミナルを agentic development environment へアップグレードしようとしています。ターミナルが shell、コードベース、コマンド実行、agent、issue、PR、協作フローをつなぐ役割を担う、という考え方です。

AI coding agent がさらに増える中で、開発環境の入口は変わるかもしれません。以前は IDE が開発体験を支配し、ターミナルはコマンド実行を担っていました。今後はターミナルが agent 協作の中心になる可能性があります。Warp のリポジトリは、その可能性を探っています。