TTS on KnightLiブログ

コンピューター用語を平易に言うと：TTS、STT、API、RAG、Agent は何を指すのか

Tue, 12 May 2026 22:15:34 +0800

コンピューター分野には、初めて聞くと難しそうに感じる用語がたくさんあります。しかし平易な言葉に置き換えると、日常のとても単純な動作を指していることが多いです。

たとえば AI が話せることは TTS、AI が人の話を聞けることは STT と呼ばれます。複雑なシステムに見えますが、分解すると「文字を読み上げる」と「音声を書き起こす」です。

参考リンク：https://www.zhihu.com/question/267978646/answer/2035405228460201515

この記事では、その視点からよくある用語をつなげて説明します。用語自体は残しつつ、意味を平易に言い換えます。

TTS と STT：文字と音声の相互変換

TTS は Text-to-Speech、つまりテキストを音声に変換することです。文字を入力すると、システムがそれを音として再生できる形にします。ナビの音声案内、電子書籍の読み上げ、AI カスタマーサポートの音声、音声アシスタントなどで使われます。

STT は Speech-to-Text、つまり音声をテキストに変換することです。スマートフォンに話しかけると、まず音声が文字に変換され、その後のプログラムに渡されます。音声入力、会議の文字起こし、自動字幕、スマートスピーカーには欠かせません。

多くの音声 AI 製品は、実際には次の流れです。

STT：あなたの発話を文字に変換する。
LLM：その文字から回答を生成する。
TTS：回答を音声として読み上げる。

自然に会話しているように見えても、内部では複数のモジュールが順番に処理しています。

OCR：画像から文字を写し取る

OCR は Optical Character Recognition、日本語では光学文字認識です。

平易に言えば、画像の中の文字を抜き出すことです。請求書を撮影する、本のページをスキャンする、身分証の名前や番号を読む、といった処理はすべて OCR です。

昔の OCR は「文字の形から推測する」ものに近かったですが、現在は深層学習を組み合わせ、複雑な背景、傾いた文字、手書き文字、低解像度画像にも強くなっています。それでも本質的な問いはシンプルです。画像の中にどんな文字があるのか、です。

NLP と LLM：機械に人間の言葉を扱わせる

NLP は Natural Language Processing、自然言語処理です。分かち書き、翻訳、要約、感情分析、質問応答、分類など、人間の言葉を扱います。

LLM は Large Language Model、大規模言語モデルです。テキストを理解し生成できるため、現在では多くの NLP タスクが LLM によって処理されています。

平易に言うと：

NLP：人が話したり書いたりする言葉を機械に処理させる。
LLM：多くの言語タスクを受け止められる大きなテキストモデル。

AI に記事を要約させる、メールを書かせる、タイトルを直させる、コードを説明させる、といったことはすべてこの方向に含まれます。

API と SDK：一方は窓口、一方は道具箱

API は Application Programming Interface です。

平易に言えば、相手が機能を呼び出すための入口を用意してくれている、ということです。天気 API は都市を渡すと天気を返し、決済 API は注文情報を渡すと決済結果を返します。

SDK は Software Development Kit です。

平易に言えば、API を呼び出しやすくするために、公式がよく使うコード、型、サンプル、ツールをまとめたものです。API がレストランの窓口なら、SDK は注文アプリのようなものです。窓口に直接伝えることもできますし、アプリを使えばより楽に注文できます。

CRUD：作成、読み取り、更新、削除

CRUD は Create、Read、Update、Delete の略です。

平易に言えば、追加、表示、編集、削除です。

多くの管理画面、業務システム、データベース操作は CRUD を中心に回っています。ユーザー管理、記事管理、注文管理、在庫管理は業務としては違って見えますが、内部ではフォームと CRUD の組み合わせであることがよくあります。

プログラマーが「また CRUD を書いた」と言うのは、それが本当に頻出するからです。

Cache：よく使うものを手元に置く

Cache はキャッシュです。

平易に言えば、よく使うものを手元に置いておき、次回は探し直したり計算し直したり問い合わせ直したりしない、ということです。

Web ページでは画像やスクリプトをキャッシュできます。遅いデータベースクエリでは人気の結果を Redis に置けます。モデル推論が高価な場合は、同じ質問への回答をキャッシュできます。

キャッシュの難しさは「コピーを置くこと」ではなく、「いつ更新するか」です。データが変わってもキャッシュが変わらなければ、古い情報が表示されます。多くのキャッシュ問題はそこから生まれます。

Queue：タスクを並べて順番に処理する

Queue はキューです。

平易に言えば、やることが多すぎるので、いったん並べて一つずつ処理することです。

たとえばユーザーが動画をアップロードしても、変換がすぐ終わるとは限りません。システムはタスクをキューに入れ、バックグラウンドサービスで後から処理できます。SMS 送信、メール送信、レポート生成、注文コールバック処理にもよく使われます。

キューが解決するのは、すべての重い処理を現在のリクエスト内で待たせないことです。ユーザーには先に応答し、時間のかかる処理は後ろで行います。

Index：データベースに目次を作る

Index はインデックスです。

データベースのインデックスは、本の目次のようなものです。目次がなければ最初のページから最後まで探す必要がありますが、目次があれば目的の場所に早くたどり着けます。

ただしインデックスは多ければよいわけではありません。検索は速くなりますが、書き込みや更新は遅くなることがあります。データが変わるとインデックスもメンテナンスする必要があるからです。

そのためデータベース最適化では「遅いクエリはまずインデックスを見る」と言われます。ただし実際に作るときは、検索条件、ソート項目、データ量、書き込み頻度も見る必要があります。

RPC、REST、Webhook：システム同士の話し方

RPC は Remote Procedure Call、リモート手続き呼び出しです。

平易に言えば、ローカル関数を呼ぶように、別のマシン上の関数を呼ぶことです。

REST は Web API でよく使われます。URL と HTTP メソッドでリソース操作を表します。たとえば GET /users はユーザー取得、POST /orders は注文作成です。

Webhook は逆方向の通知です。こちらが「終わった？」と何度も聞くのではなく、相手が処理完了後にこちらの URL へ通知します。

簡単に覚えるなら：

RPC：遠隔の関数を呼ぶ。
REST：HTTP でリソースを管理する。
Webhook：出来事が起きたら相手から知らせてもらう。

CDN と Load Balancing：近くに置く、負荷を分ける

CDN は Content Delivery Network、コンテンツ配信ネットワークです。

平易に言えば、静的リソースをユーザーに近いノードへ置くことです。画像、動画、CSS、JS にアクセスするとき、毎回オリジンサーバーまで行く必要がなくなります。

Load Balancing は負荷分散です。

平易に言えば、アクセスが多すぎるときに一台のサーバーだけに背負わせず、複数のマシンへリクエストを分けることです。

一方は「ユーザーに近づける」、もう一方は「一台を疲れさせない」ための仕組みです。大規模サイトでは通常どちらも使われます。

Docker、Container、Kubernetes：パッケージ化、実行、配置

Docker は代表的なコンテナツールで、Container はコンテナです。

平易に言えば、プログラムと依存環境をまとめてパッケージ化し、別のマシンでもできるだけ同じように動かす仕組みです。「自分の PC では動くのにサーバーでは動かない」問題を減らします。

Kubernetes はよく K8s と書かれる、コンテナオーケストレーションシステムです。

平易に言えば、コンテナがたくさんあるときに、どこで動かすか、落ちたらどう再起動するか、トラフィックをどう分けるか、バージョンをどう更新するかを管理します。

小さなサービスが一つだけなら Docker で十分なこともあります。多くのサービス、マシン、レプリカがある場合に K8s の価値が出ます。

CI/CD：自動ビルド、自動リリース

CI は Continuous Integration、継続的インテグレーションです。

平易に言えば、コードがコミットされると、システムが自動でコードを取得し、テストし、ビルドして、早めに問題を見つけることです。

CD は Continuous Delivery または Continuous Deployment を指します。

平易に言えば、ビルドが通った後、コードをより安定して自動的にテスト環境や本番環境へ届けることです。

これは「コードを書く」問題ではなく、「書いた後にどう少ないミスでリリースするか」の問題を解決します。

Serialization：オブジェクトを送れる形式に詰める

Serialization はシリアライズです。

平易に言えば、プログラム内のオブジェクトを保存・送信できる形式に変えることです。JSON、XML、Protobuf などが例です。

逆に Deserialization は、それらの形式をプログラムで使えるオブジェクトに戻すことです。

フロントエンドとバックエンドが JSON をやり取りするとき、サービス同士が Protobuf を使うとき、どちらもシリアライズが関わっています。

Token、Embedding、Vector DB：文字をモデルが扱える形にする

大規模モデルにおける Token は、テキストを分割した基本単位を指します。必ずしも漢字一文字や英単語一つではなく、モデル内部でテキストを処理する粒度のようなものです。

Embedding は埋め込みベクトルです。

平易に言えば、文字、画像、その他の内容を数字の列に変換し、モデルが類似度を比較できるようにすることです。

Vector DB はベクトルデータベースです。

平易に言えば、それらのベクトルを保存し、「意味が近い」内容を素早く探せるデータベースです。

たとえば「ルーターをリセットする方法」と聞くと、システムはベクトルデータベースから「工場出荷状態に戻す」「Wi-Fi パスワードを忘れた」「管理画面にログインできない」といった近い内容を探し、モデルに参考資料として渡します。

RAG：先に資料を調べてから答える

RAG は Retrieval-Augmented Generation、検索拡張生成です。

平易に言えば、モデルが答える前に、まず資料庫から関連内容を探し、その資料を持って回答することです。

これは大規模モデルが記憶だけで適当に答えてしまう問題を和らげます。企業文書、ナレッジベース、製品マニュアル、コード片をつなぐことで、モデルは学習時の記憶だけでなく、あなたが与えた最新資料を参照できます。

典型的な流れは：

ユーザーが質問する。
システムが質問を Embedding に変換する。
Vector DB から関連文書を探す。
文書片と質問を一緒に LLM へ渡す。
モデルが回答を生成する。

つまり RAG は難しそうに聞こえますが、本質は「先に資料を調べてから、言葉を組み立てる」です。

Agent：タスクを分解できる自動化フロー

AI 文脈での Agent は、しばしばエージェントや智能体と呼ばれます。

平易に言えば、単に一文を返すだけでなく、目標をステップに分け、ツールを呼び出し、結果を観察し、次の行動を決められるものです。

たとえば「このリポジトリのテストが失敗する理由を分析して」と頼むと、通常のチャットモデルは助言だけを返すかもしれません。Agent なら、ファイルを読み、テストを実行し、エラーを確認し、コードを修正し、再度テストを走らせる可能性があります。

もちろん Agent は必ず信頼できるという意味ではありません。実態は「モデル + ツール呼び出し + 状態ループ」です。使いやすさは、ツール権限、タスク境界、エラー処理、人間の確認設計に左右されます。

まとめ

多くのコンピューター用語が難しそうに見えるのは、英語の略語、アーキテクチャ図、製品文言に包まれているからです。分解すると、多くは素朴な動作を表しています。

TTS：文字を読み上げる。
STT：音声を書き起こす。
OCR：画像から文字を写す。
API：呼び出し口を公開する。
SDK：呼び出し用の道具をまとめる。
CRUD：作成、読み取り、更新、削除。
Cache：よく使う結果を保存する。
Queue：タスクを並べて後で処理する。
Index：データに目次を作る。
CDN：コンテンツをユーザーに近づける。
Load Balancing：リクエストを分散する。
Docker：実行環境をパッケージ化する。
CI/CD：テストとリリースを自動化する。
Embedding：内容を数値ベクトルにする。
RAG：先に資料を調べてから答える。
Agent：モデルにツールを使わせて段階的に作業させる。

用語は検索、コミュニケーション、ドキュメント参照に便利なので残すべきです。ただし理解するときに怖がる必要はありません。まず平易な言葉に訳し、それから技術的な細部へ戻ると、多くの概念はずっと分かりやすくなります。

参考

Zhihu 回答：https://www.zhihu.com/question/267978646/answer/2035405228460201515

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 は試して分解してみる価値があります。