OpenCode Viewerとは?OpenCodeのセッションを可視化・操作できるWebクライアントを解説

目次
- 1 OpenCode Viewerとは?OpenCodeのセッションを可視化・操作できるWebクライアントを解説
- 2 OpenCode Viewer入門:初心者が知っておきたい基本概念とセッション操作ガイド【徹底解説】
- 3 OpenCode Viewerインストール方法:npxで即起動、npmでグローバル導入、ソースからビルド
- 3.1 npxによるOpenCode Viewerのクイック起動方法:コマンド一発でローカルに起動する手順を解説
- 3.2 npmを使ったOpenCode Viewerのグローバルインストール手順:npm installでシステムに導入する方法
- 3.3 GitHubリポジトリからソースをビルドして起動する方法:pnpmで依存解決してビルド・起動する手順
- 3.4 OpenCode Viewerのデフォルト起動ポートと変更方法:標準ポート3400の確認とカスタマイズ手順
- 3.5 OpenCode ViewerとOpenCodeストレージの接続設定:OPENCODE_STORAGE_ROOT環境変数でパス指定
- 4 OpenCode Viewerアーキテクチャ概要:フロント/バックエンド構成と動作の仕組みを詳しく解説
- 5 重要コンポーネントをコードで理解する:タスク制御やSSE連携などOpenCode Viewer内部処理を徹底解説
- 6 セッションの一覧・検索・並び替え機能:豊富なオプションで過去セッションを効率管理する方法【徹底解説】
- 7 セッション詳細でのタイムライン表示:ユーザー・AI・ツール別の対話履歴を見やすく可視化する仕組みを解説
- 8 実行中タスクのステータス監視と中断:進行状況のリアルタイム把握と中断・再開操作の方法とポイントを詳しく解説
- 9 Git統合で差分確認:ブランチ・コミットの可視化と未追跡ファイルを含むDiff機能の使い方を徹底解説
- 10 ファイル補完APIでパス入力支援:対話時のパス入力を便利にする自動補完機能の仕組みと使い方を詳しく解説
OpenCode Viewerとは?OpenCodeのセッションを可視化・操作できるWebクライアントを解説
OpenCode Viewerは、AIコーディングツールOpenCodeの対話セッションやツール実行結果をブラウザ上で直感的に可視化し、セッションの再開やタスク状況の管理を可能にするWebクライアントです。OpenCodeによるAI開発が進む中、対話ログや実行履歴を手軽に「見える化」したいというニーズから生まれました。
OpenCode Viewerが登場した背景と目的:AI駆動開発でWeb可視化ツールが求められた理由
OpenCodeを用いたAI開発が広がる中、大量の対話ログやツール実行履歴を効率よく把握するための「見える化」ツールが求められていました。従来、OpenCodeはCLIやTUIで操作しますが、長時間のセッションでは履歴を遡るのが大変です。そこで既存のCodex Viewerを基に派生した「OpenCode Viewer」が開発され、ブラウザ上でログを俯瞰・管理できるようになりました。
OpenCode Viewerの主な機能と特徴:セッション可視化・タスク中断・Git連携など充実の機能一覧
OpenCode Viewerの主な機能として、以下のようなポイントが挙げられます。
- セッション一覧の表示・検索・並び替え: 過去の対話セッションを一覧で表示し、キーワード検索や日付順・タイトル順でソートできます。
- セッション詳細のタイムライン表示: 各セッションのユーザー入力、アシスタント回答、AI推論過程、ツール呼び出しとその結果を時系列のタイムラインで見やすく表示します。
- 実行中タスクのステータス監視と中断: OpenCodeで実行中のタスクの状況(running/waiting/completed/failed)をリアルタイムに監視し、必要に応じて途中でAbort(中断)できます。
- リアルタイム更新(SSE): セッションデータの変更をサーバー側で検知し、SSE(Server-Sent Events)でブラウザにプッシュ通知することで、ログ表示やタスク状態を自動更新します。
- Git統合による差分確認: プロジェクトのGitリポジトリと連携し、現在のブランチ名やコミット一覧を表示できるほか、ファイルの変更差分(diff)をビューア上で確認できます(未コミットの新規ファイルについても差分を表示)。
- ファイル補完APIでパス入力支援: 対話入力中にファイルパスを入力する際、指定ディレクトリ配下のファイル名候補を自動表示し、パス入力をサポートします。
OpenCode Viewerを利用するメリットとユースケース:開発効率向上や履歴管理に寄与するポイント
OpenCode Viewerを活用することで、以下のようなメリットやユースケースがあります。
- 過去のセッションを簡単に再開できる:ビューアでセッション一覧から目的の対話を見つけ、セッションIDをコピーしてすぐにCLIで
opencode run --session
を実行できます。 - 長時間実行中のタスクの状況を把握しやすい:ビューア上部のステータス表示でrunning中の処理を監視し、進行が止まった場合はAbortボタンで即座に停止して、改めて対話を再開できます。
- 重複したタイトルのセッションを統合表示:同じプロジェクト内で同名のセッションが複数ある場合でも、設定により一覧上で1つにまとまって表示されるため履歴を整理できます。
- ブラウザ上でコード差分を確認可能:ViewerのGit差分表示で、レビュー時に変更内容を俯瞰でき、特に未追跡ファイルの新規追加分も見落とさずに確認できます。
- 対話入力でパスを補完:ファイルパスをタイプしている途中で候補が出るため、正確なパスを思い出せなくても素早く入力でき、生産性が向上します。
OpenCode ViewerとOpenCode(CLI/TUI)の関係:CLIツールとの違いと連携方法
OpenCode ViewerはあくまでOpenCodeのフロントエンド的な位置づけであり、OpenCode本体(CLI/TUI)が生成するセッションデータを読み込んで表示します。OpenCode CLIで対話を進める裏で、Viewerはその内容(ユーザー入力やAIの出力、ツールの結果)をリアルタイムに取得・可視化します。またViewerから新規セッション開始や中断を指示すると、内部的にはOpenCode CLIのコマンドが実行されます。このように、CLI/TUIの操作性とViewerの視覚的UIが連携することで、OpenCodeをより快適に利用できるようになります。
類似ツール(Codex Viewerなど)との比較:他のセッション可視化ツールとの違いと優位性を解説
OpenCode ViewerはClaude Code Viewer(通称Codex Viewer)をベースに作られており、その洗練されたUI/UXを受け継いでいます。Codex ViewerはOpenAIのコード対話環境向けに開発されたツールでしたが、OpenCode ViewerではOpenCodeのセッション保存形式に合わせた対応や、タスク制御・ファイル監視といったOpenCode特有の機能統合がなされています。これにより、CLI/TUIだけでは見えづらかった部分も含めて、OpenCode利用時の体験を向上させる独自のツールとなっています。他の一般的なログ閲覧手段(例えば生のJSONファイルを直接見るなど)に比べても、OpenCode Viewerははるかに効率的かつ高機能です。
OpenCode Viewer入門:初心者が知っておきたい基本概念とセッション操作ガイド【徹底解説】
ここからは、OpenCode Viewerを実際に使い始めるにあたって知っておきたい基本事項や手順を説明します。必要な前提環境の準備から、Viewerの起動方法、画面の基本構成、セッション履歴の表示・再開方法まで、一通りの流れを見ていきましょう。
OpenCode Viewerの前提条件と必要環境:OpenCode CLIやNode.js環境の準備事項
OpenCode Viewerを利用するには、前提としてOpenCode本体(AIと対話しながらコーディングを行うCLIツール)がインストールされている必要があります。また、Viewer自体はNode.js製のWebアプリケーションのため、Node.jsの実行環境も必要です。OpenCodeが生成するセッションデータを読み込むため、OpenCode CLIでいくつかセッションを実行済みであることが望ましいでしょう。さらにGit差分機能を使うにはGitリポジトリが初期化されているプロジェクトでViewerを開く必要があります。
OpenCode Viewerの起動と初期設定の手順:ローカルホスト起動と自動ブラウザオープン設定の確認
OpenCode Viewerはコマンドラインから起動するWebサーバーとして動作します。インストールせずに試す場合はnpx @nogataka/opencode-viewer
で即座に起動でき、あるいはnpmでグローバルインストールした上でopencode-viewer
コマンドを実行することもできます(詳細なインストール方法は後述)。起動するとデフォルトではhttp://localhost:3400でWebインターフェースが立ち上がり、自動でブラウザが開きます(自動起動を抑制したい場合は環境変数CC_VIEWER_NO_AUTO_OPEN=1
を設定)。初回起動時に特別な設定は不要で、そのままセッション一覧画面が表示されます。
OpenCode Viewerの基本画面とUI構成:セッション一覧・詳細画面の画面構成と機能概要を詳しく紹介
OpenCode Viewerの画面構成は大きく2つに分かれます。初期画面ではすべてのセッションがリスト形式で表示され、各セッション名や最終更新日時、メッセージ数などの情報を確認できます。特定のセッションをクリックすると詳細ビューに切り替わり、右側にタイムライン形式の対話履歴が表示されます。画面上部のヘッダーには実行中タスク数がバッジで表示され、進行中の処理が一目でわかるようになっています。また、画面の一部に検索バーやフィルタ設定ボタンが用意されており、セッションの絞り込みや表示オプションを切り替え可能です。
セッションを読み込んで履歴を表示する方法:過去セッションの選択からタイムライン確認までの手順を詳しく解説
Viewerで特定のセッションの履歴を表示するには、まずセッション一覧から目的のセッションを選択します。クリックすると、そのセッションの詳細画面に移動し、これまでの対話履歴が時系列順にタイムライン表示されます。ユーザーの入力、アシスタントの回答、さらにはAIが裏で行った推論や外部ツールの呼び出し結果まで、一連の流れとして表示されるため、会話の文脈を簡単に追うことができます。実行中のセッションであれば、新しいメッセージやツール結果が生成され次第、リアルタイムにタイムラインに追加表示されるため、ブラウザをリロードせずとも最新の状況を把握可能です。
OpenCode Viewerで対話を再開するフロー:中断したセッションにメッセージを送るまでの手順
中断した対話セッションを再開する際も、OpenCode Viewerが役立ちます。セッション詳細画面では対象セッションのセッションIDが簡単にコピーできるようになっており、そのIDを用いてターミナルからopencode run --session <セッションID>
を実行すれば、前回の続きから対話を再開できます。また、Viewer上でAbortしたタスクを再開したい場合は、新たにユーザー入力を送信し直すことで同じセッションIDのもと対話を継続可能です(Abort操作はセッション自体を終了しないため、対話履歴を引き継げます)。このように、Viewerを併用することで中断・再開がスムーズに行えるようになります。
OpenCode Viewerインストール方法:npxで即起動、npmでグローバル導入、ソースからビルド
OpenCode Viewerの導入は容易で、目的に応じていくつかの方法が用意されています。以下では、即時起動からグローバルインストール、ソースコードからのビルドまで、それぞれの手順を説明します。
npxによるOpenCode Viewerのクイック起動方法:コマンド一発でローカルに起動する手順を解説
最も手軽な方法は、npxを用いてOpenCode Viewerをその場で起動するやり方です。例えば以下のコマンドを実行すると、プロジェクトにインストールすることなくViewerが立ち上がります:
PORT=3400 npx @nogataka/opencode-viewer@latest
上記ではポート3400
でサーバーが起動します(PORT変数を省略すればデフォルトの3400番ポートが使用されます)。この方法では、グローバルインストールの必要がなく、素早くViewerを試せるのが利点です。
npmを使ったOpenCode Viewerのグローバルインストール手順:npm installでシステムに導入する方法
OpenCode Viewerを頻繁に利用する場合は、npmでグローバルインストールしておくと便利です。以下のコマンドでパッケージをインストールできます:
npm install -g @nogataka/opencode-viewer
インストール後、コマンドopencode-viewer
を実行するとViewerが起動します。毎回npxで取得する必要がなくなるため、ネットワーク接続がない環境でも素早く立ち上げられる利点があります。
GitHubリポジトリからソースをビルドして起動する方法:pnpmで依存解決してビルド・起動する手順
OpenCode Viewerはオープンソースで提供されており、自分でビルドして使用することも可能です。開発者向けにはこちらの方法がおすすめです。まずGitHubからリポジトリをクローンします:
git clone https://github.com/nogataka/opencode-viewer.git
cd opencode-viewer
次に依存関係をインストールし、ビルド・起動を行います(パッケージ管理ツールにはpnpmを使用しています)。
pnpm install
pnpm build
pnpm start
ビルドが成功するとローカルにViewerサーバーが起動し、ソースコードに加えた変更が反映された状態で動作を確認できます。
OpenCode Viewerのデフォルト起動ポートと変更方法:標準ポート3400の確認とカスタマイズ手順
OpenCode Viewerはデフォルトではポート3400
番で起動します。例えば上記のnpxコマンドやグローバルインストールで起動した場合も、自動的にlocalhost:3400を使用します。他のアプリケーションとポートが競合する場合や別のポートを使いたい場合は、環境変数PORT
を指定して起動することで変更可能です(例: PORT=3000 opencode-viewer
と実行すれば3000番ポートで起動)。ポートを変更した場合は、ブラウザで開くURLもポート番号に応じて変更する必要がある点に注意してください。
OpenCode ViewerとOpenCodeストレージの接続設定:OPENCODE_STORAGE_ROOT環境変数でパス指定
OpenCode Viewerは、OpenCode CLIが保存するセッションデータのディレクトリを監視して読み込みます。標準では~/.local/share/opencode/storage/
以下のsession/
やmessage/
ディレクトリを自動的に参照しますが、OpenCodeのストレージパスを変更している場合でも安心です。環境変数OPENCODE_STORAGE_ROOT
にカスタムのストレージパスを設定すれば、Viewerはそのパスを基点にセッションデータを監視します。例えばストレージをプロジェクト直下に変更しているなら、Viewer起動前にexport OPENCODE_STORAGE_ROOT=/path/to/your/storage
と設定してください。この接続設定により、Viewerは正しい場所からセッション情報を取得できます。
OpenCode Viewerアーキテクチャ概要:フロント/バックエンド構成と動作の仕組みを詳しく解説
OpenCode ViewerはモダンなWebアプリケーションとして構築されており、フロントエンドとバックエンドが連携する形で動作します。フロントエンドはブラウザ上で動作し、バックエンドはNode.js上でAPIサーバーとして機能します。セッションデータの監視やリアルタイム更新の仕組みなど、内部のアーキテクチャに工夫が凝らされています。ここでは、その概要を技術スタックとともに解説します。
フロントエンド(Next.js/React)の構成と役割:最新Next.js 15とReact 19の採用理由
OpenCode ViewerのフロントエンドはNext.js 15とReact 19を採用しています。Next.jsによりパフォーマンス最適化やビルド周りの利便性を得つつ、最新のReact機能を活用したリッチなUIを実現しています。またデータ取得にはTanStack Query(旧React Query)を用いており、セッションやタスク状態といったデータをキャッシュしつつ効率的にSSE更新と同期しています。状態管理には軽量なJotaiを組み合わせ、UIコンポーネント間で必要な情報(例えば現在閲覧中のセッションIDや実行中タスク一覧など)をシンプルかつ高速に共有しています。これら最新フロントエンド技術の採用により、滑らかなユーザー体験とメンテナンス性の高いコード基盤を両立しています。
バックエンド(Hono/SSE)の構成とリアルタイム通信:Node製APIとサーバー送信イベントの仕組み
バックエンド側では、Honoと呼ばれる軽量なNode.js向けWebフレームワークを使用してAPIサーバーを構築しています。Honoにより、OpenCode Viewer専用のAPIエンドポイント(セッション開始・再開、中断、タスク状態取得など)が実装され、フロントエンドからのリクエストに応答します。さらに、Viewerの特徴であるSSE(Server-Sent Events)によるリアルタイム通信もバックエンドで担っています。SSEを用いることで、サーバー側からブラウザ側へイベントをプッシュ配信し、ログやステータスの変化を即座にUIに反映させています。Node.js上で動作するこれらのバックエンド機能により、OpenCode CLIの動作状況とブラウザUIがシームレスに同期する設計となっています。
OpenCodeストレージ監視対象とデータ構造:session/message/part各ディレクトリの内容
OpenCode Viewerのバックエンドは、OpenCodeが書き出すファイルを直接監視することでデータ更新を検知しています。既定では~/.local/share/opencode/storage/
以下に、セッションごとのディレクトリがあり、その中にsession/
(セッション情報)、message/
(各メッセージ内容)、part/
(ツール実行結果などの付加情報)というJSONファイル群が配置されます。Viewerはこれらのディレクトリをfs.watch
で監視し、ファイルに変更が生じると即座にキャッチします。例えば、新しいユーザー入力のメッセージJSONが保存されればそれを検知し、またツール実行結果のパーツファイルが生成されても把握します。こうした監視対象のデータ構造を理解することで、ViewerがどのようにOpenCodeの内部状態を追跡しているかが分かります。
セッションIDの生成と管理(base64url方式):人に読みやすく衝突しないID設計の工夫を詳しく解説
OpenCode Viewerではセッションを一意に識別するためのセッションIDの扱いにも工夫があります。OpenCode CLIは各セッションに対してUUIDを付与しますが、Viewer上ではファイルパスから生成したIDをbase64url形式で表現しています。これにより、人間にも扱いやすい短い文字列となりつつ、パスの特殊文字を含まない安全なIDになります。たとえばセッションの保存パスが長く複雑でも、それをbase64urlエンコードしたIDで画面上に表示することで、コピー&ペーストや共有が容易になります。また同じファイル名でディレクトリが異なる場合などでもユニーク性が保たれ、衝突しない仕組みになっています。
サービスモジュールの構成(Git操作・ファイル補完など):server/service下の機能分割を解説
OpenCode Viewerのサーバーサイドコードは、機能ごとにモジュール分割されています。特にGit関連操作やファイルパス補完などは、src/server/service/
配下に専用のサービスモジュールとして実装されています。例えばGit統合の処理はGitサービスモジュールに、ファイル補完APIの処理はファイル補完サービスモジュールに分けられており、それぞれ独立したコードとして保守・拡張が可能です。こうしたモジュール構成により、新たな機能追加や特定機能の改良がしやすく、OpenCode Viewer全体のアーキテクチャが整理されています。
重要コンポーネントをコードで理解する:タスク制御やSSE連携などOpenCode Viewer内部処理を徹底解説
OpenCode Viewerの内部では、いくつかの重要なコンポーネントが密接に連携して動作しています。ここでは、コード上で特に要となる部分を抜粋し、その仕組みを解説します。具体的には、タスクの実行管理、APIルート、ファイル監視、セッションデータ整形、Git差分処理といった機能ブロックについて、そのコードから内部動作を理解していきましょう。
タスク制御(OpencodeTaskController)の仕組み:OpenCode CLIプロセス管理とキュー実行
OpenCode Viewerのバックエンドには、OpenCode CLIプロセスを管理するOpencodeTaskControllerというコンポーネントがあります。新しいユーザー入力を受け取ると、このコントローラが内部でopencode run --format json
コマンドを子プロセスとして起動し、OpenCode CLIに処理を委ねます。--format json
オプションによりCLIからはJSON形式で逐次結果が出力されるため、コントローラ側でそれをパースして重要な情報(例えばセッションのUUID)が取得できます。最初の出力で得られたUUIDからViewer用のセッションID(パス由来のID)も確定し、以降の出力をそのセッションに紐付けて管理します。またOpencodeTaskControllerは複数のタスクが同時に実行されないよう直列的なキューを持ち、あるタスクが終了するとキュー内の次のタスクを開始する仕組みです。そして各タスクの状態変化(開始、完了、失敗など)が起きるたびにtask_changed
イベントを発行し、SSE経由でフロントエンドに通知します。これにより、ユーザーはブラウザ上でタスクの進行状況をリアルタイムに把握できるのです。
セッション開始・再開・中断を管理するHonoルート:APIエンドポイントでタスク制御する実装を詳しく解説
OpenCode ViewerのバックエンドAPI(Hono)は、セッションの開始・再開やタスク中断に対応するルートを提供しています。例えば、新規セッション開始用のPOST /projects/:projectId/new-session
エンドポイントでは、リクエストからユーザー入力メッセージを受け取り、該当プロジェクトのワークスペースでtaskController.startOrContinueTaskメソッドを呼び出します。ここでOpenCode CLIの新規実行がトリガーされ、生成されたtaskId
やsessionId
がレスポンスとして返されます。同様に、/sessions/:sessionId/resume
エンドポイントでは既存セッションIDを指定して対話を再開するAPIを提供しています。また、GET /tasks/alive
では現在実行中の全タスク一覧を取得でき、POST /tasks/abort
では指定したセッションIDのタスクを強制中断します。これらHonoルートの実装により、フロントエンド側からセッション管理やタスク操作がHTTP経由で行えるようになっています。
ファイル監視とリアルタイム更新の実現方法:fs.watchによるOpenCodeデータ変更検知とSSE送信
OpenCode Viewerがリアルタイム更新を実現できている鍵は、ファイルシステムの監視にあります。バックエンドではfs.watch
を用いてOpenCodeのストレージディレクトリ配下(セッション関連のJSONファイル群)を監視し、ファイルの追加・変更イベントを捕捉しています。具体的には、まずsession/.json
ファイルの変化でセッション自体の更新を検知し、さらにmessage/.json
やpart/*.json
ファイルの生成・変更も監視して、アシスタントの新規回答やツール実行結果の到着を即座に把握します。これらのイベントが検知されると、Viewerは内部イベントバスを通じてproject_changed
やsession_changed
といったイベントを発行し、SSE経由でフロントエンドに通知します。フロントエンド側では受け取ったイベントに応じてReact Queryのキャッシュを適切に再取得し、新しいデータをレンダリングしてUIを同期します。こうした仕組みにより、ユーザーは手動でリロードすることなく常に最新のセッション状態を閲覧できるのです。
セッション解析とタイムライン整形のロジック:メッセージ+パーツを統合し見やすく整形する処理を詳しく解説
OpenCodeでは、ユーザーのメッセージに対するAIの回答テキストだけでなく、その途中で呼び出されたツールの結果やAIの内部推論ログ(思考過程)などが「パーツ」として記録されます。OpenCode Viewerは、こうしたメッセージとパーツを組み合わせて、人間が読みやすいタイムラインに整形するロジックを備えています。コード上では、各セッションのメッセージ一覧に対応するパーツ一覧を走査し、テキスト種類のパーツであればその内容を整形してメッセージの直後に挿入するなど、時系列に沿った一本の対話ストーリーにまとめ上げます。またユーザー/アシスタント/ツールといった発話者種別ごとにフォーマットや表示スタイルを変えることで、誰の発言・結果なのかが直感的に区別できるよう工夫されています。このように、コードによるデータ整形処理によって、生のJSONログが見やすい対話履歴に変換されて表示されます。
Git差分表示機能のユニークな実装:未追跡ファイルに対する人工的なDiff生成ロジックのポイントを詳しく解説
OpenCode ViewerのGit差分表示機能には、未追跡(Untracked)の新規ファイルに対しても差分を表示するというユニークな実装があります。通常、git diff
ではバージョン管理下の変更のみが表示され、まだgit add
していない新規ファイルの中身は一覧できません。そこでViewerでは、ライブラリparse-git-diff
を用いて通常の差分情報を解析しつつ、未追跡ファイルに関してはファイルの内容を読み込んで行ごとの疑似的な差分を生成しています。具体的には、新規ファイル内の全ての行を「追加された行」とみなして人工的なdiffのhunkを作り、既存の差分結果に組み込んでいます。この工夫により、まだコミットしていないファイルも含めてViewer上のDiffビューで変更点を俯瞰でき、レビュー時の見落としを減らすことができます。
セッションの一覧・検索・並び替え機能:豊富なオプションで過去セッションを効率管理する方法【徹底解説】
OpenCode Viewerのセッション一覧画面では、過去の対話セッションを効率良く管理するための様々な機能が提供されています。セッションの検索やフィルタリング、並び替えなどを活用して、目的の履歴に素早くアクセスできます。
セッション一覧画面の基本UIと表示内容:セッション名・日時・進行状況の一覧表示内容を詳しく解説【画面例付き】
セッション一覧画面では、現在のプロジェクト内に保存されている全てのセッションが一覧化されます。各セッションにはタイトル(または開始メッセージの冒頭)、最終更新日時、含まれるメッセージ数などの情報が表示され、一目でセッションの内容と最近の更新状況を把握できます。実行中のセッションがある場合はその状態が特別なアイコンや色で示され、そうでない過去セッションは通常のリスト項目として表示されます。視認性の高いUIデザインにより、どのセッションにどんな対話が行われたかを効率的に俯瞰できるようになっています。
セッション検索機能と絞り込みオプション:キーワード検索とセッションフィルタ機能の使い方とコツを詳しく解説
セッション数が多くなっても、Viewerの検索機能と絞り込みオプションで目的のセッションを容易に見つけ出せます。画面上部の検索バーにキーワードを入力すると、セッションタイトルや内容にその文字列が含まれるセッションだけにリストがリアルタイム更新されます。また、チェックボックスやトグルスイッチによるフィルタリングも可能で、例えばユーザー入力がない空のセッションを非表示にする設定(hideNoUserMessageSession
)を有効にすれば、開始メッセージが記録されていないセッションを一覧から除外できます。これらの検索・フィルタ機能により、条件に合致するセッションだけに絞り込んで表示でき、過去ログの管理が格段に楽になります。
セッションの並び替え基準とソート順序:更新日時やタイトル順で表示順を変更する方法とデフォルト設定を詳しく解説
セッション一覧の並び順は、ユーザーの好みに応じて変更可能です。デフォルトでは最新更新順(最終更新日時が新しい順)にソートされ、最近アクティブだったセッションが上位に表示されます。必要に応じてタイトル順(アルファベットまたは五十音順)で並び替えることもでき、関連するセッションをグルーピングして確認したい場合に便利です。ソート順の切り替えはUI上のメニューやボタンから行え、選択すると即座にリストの順序が変更されます。自分にとって見やすい順序で履歴を整理できるため、多数のセッションを扱う場合でも目的のものをスムーズに見つけられるでしょう。
重複タイトルセッションの統合表示機能:同じタイトルのセッションをまとめて表示する方法と設定を詳しく解説
OpenCodeでは、同じタイトル(例えば全く同じユーザー質問)で複数のセッションが作られるケースがあります。OpenCode Viewerにはそうした重複タイトルのセッションを統合表示する機能が用意されており、設定でunifySameTitleSession
オプションを有効にすると、一覧上で同名のセッションが一つにまとまって表示されます。統合表示されたセッションを選択すると、内部では複数のセッションのログがまとめてタイムライン表示され、重複部分を意識せず連続した履歴として閲覧できます。これにより、似通った対話ログが分散して一覧を埋めてしまうのを防ぎ、過去の対話履歴を整理された形で参照することが可能になります。
最初のユーザー入力がないセッションを非表示にする設定:hideNoUserMessageSessionオプションの活用
OpenCode利用中に、ユーザーからの入力がないまま生成されてしまったセッション(例えば実験的にセッションを開いただけで何も対話しなかった場合など)が存在することがあります。Viewerの設定項目hideNoUserMessageSession
を有効にすると、こうした最初のユーザー入力が存在しないセッションを一覧から非表示にできます。デフォルトでは全てのセッションが表示されますが、このオプションにより実質的な対話のない空セッションをリストから排除でき、ノイズを減らして履歴管理をシンプルにします。本格的な対話が行われたセッションだけを見たい場合に有用なフィルタ機能と言えます。
セッション詳細でのタイムライン表示:ユーザー・AI・ツール別の対話履歴を見やすく可視化する仕組みを解説
OpenCode Viewerのセッション詳細画面では、一つの対話セッション内のやり取りが時系列に沿ったタイムライン形式で表示されます。メッセージの送り手や内容がひと目で区別できるよう工夫されており、過去の対話履歴を追いやすくなっています。
セッション詳細画面のUI構成とタイムライン表示領域:メッセージ履歴とステータス表示の配置を詳しく解説
セッション詳細画面では、そのセッション内の全ての対話がタイムライン形式で一覧できます。画面の大部分を占めるタイムライン表示領域には、ユーザーとアシスタントのメッセージ、およびAIが途中で実行したツールの出力結果(パーツ)が発生順に並べられます。各発言や結果にはタイムスタンプや発言者の区分が付記されており、対話の流れと時系列が直感的に把握できます。必要に応じてスクロールすることで最初から最後までの履歴をさかのぼって確認でき、長いセッションであっても一画面で全体像を掴むことができます。また、詳細画面上部にはセッション名や操作ボタン(例: 実行中タスクのAbortボタン)が配置され、履歴を見ながらセッション操作を行えるUIになっています。
ユーザー・アシスタント・ツール結果の視覚的区別:発話者ごとの色分けやラベル表示などUI上での見分け方を解説
タイムライン上では、ユーザーの発言、アシスタント(AI)の応答、そしてツールの実行結果が一目で判別できるよう視覚的な工夫が凝らされています。例えばユーザーのメッセージは左側に表示され、背景色もアシスタントのものと異なる色で強調されます。アシスタントからの回答メッセージは右側または別の色で表示され、どちらがユーザーでどちらがAIかがすぐ分かります。また、ツールを呼び出した際の結果ログについては、専用のアイコンやラベル(「ツール出力」等)が付与され、メッセージとは異なるスタイルでタイムラインに挿入されます。これにより、対話の中で誰(または何)の発言・出力であるかが視覚的に区別され、複雑なやり取りでも混乱せずに読み解くことができます。
タイムライン上でのメッセージとパーツの統合表示:ユーザー発言とツール実行結果を一連の流れで表示する仕組み
OpenCode Viewerでは、AIアシスタントが内部で行ったツール呼び出しや思考結果(パーツ)も、通常のメッセージと統合して表示されます。例えば、ユーザーからの質問に対してアシスタントがコードを生成し、その途中で外部コマンドを実行して得た結果がある場合、タイムライン上では「ユーザーの質問」→「アシスタントの思考(ツール実行)」→「ツールの出力結果」→「アシスタントの回答続き」というように、一連の流れとして表示されます。これにより、AIの応答に至るまでの過程を含めて、対話の全体像を把握できます。メッセージとパーツが時系列順にシームレスに組み合わさっているため、ユーザーは背後で何が起きていたのかを含めて会話内容を追跡することができます。
対話履歴を時系列で追いやすくする工夫:時系列ソートと視覚的インデントで文脈を把握するポイントを詳しく解説
Viewerのタイムライン表示は、最新のイベントから過去の履歴までを自然な時系列で追えるようデザインされています。新しいメッセージや結果が届くとタイムラインの末尾に順次追加されていくため、現在進行中の対話もリアルタイムで追跡可能です。また、ログの各エントリにはタイムスタンプが付与されているため、いつ何が起こったかを正確に把握できます。視覚的にも、吹き出し形式のメッセージ表示やインデントによる階層構造の表現により、会話の流れや文脈が掴みやすくなっています。これらの工夫により、長大な対話履歴であっても途中の文脈を見失うことなく、最初から最後まで一貫したストーリーとして理解することができます。
OpenCode Viewerでセッション詳細をリアルタイム更新する仕組み:進行中の出力が逐次反映される流れ
OpenCode Viewerのタイムラインは、リアルタイムに更新されるため、ユーザーは対話の進行状況を逐次見守ることができます。Viewerを開いた状態でOpenCodeが新たな出力を生成すると、その内容が即座にタイムラインに反映されます。例えば、AIが長いコード出力を行っている場合、そのコードが生成され終わるのを待たず、進捗に応じて部分的にタイムラインに表示されていきます(OpenCode CLIが逐次JSONを出力するため、それをリアルタイム描画しています)。これにより、ユーザーは処理が完了するのを待ちながら逐一ブラウザをリロードしたりログファイルを開き直したりする必要がありません。対話やタスクの最新状況が自動で更新されるため、まるでリアルタイムチャットを見ているかのような感覚でOpenCodeとやり取りできるのがViewerの利点です。
実行中タスクのステータス監視と中断:進行状況のリアルタイム把握と中断・再開操作の方法とポイントを詳しく解説
OpenCode Viewerは、バックエンドで実行しているAIタスク(対話の進行やコード生成など)の状況を可視化し、必要に応じてユーザーがそれを中断できる機能を備えています。これにより、長時間走り続ける処理の進捗を確認したり、不必要になった処理を途中で止めたりすることが容易になります。
進行中タスクの一覧表示とステータスインジケータ:サイドバーやヘッダーでのタスク状況の表示方法を詳しく解説
OpenCode Viewerでは、現在実行中のタスクを確認するためのUIが用意されています。画面のヘッダー部分やサイドバーには、進行中のタスク数がバッジ付きで表示され、クリックすると詳細なタスク一覧が展開されます。タスク一覧には各タスクのセッション名や状態(実行中、待機中など)が表示され、複数のタスクがキューに入っている場合でも一目で把握可能です。例えば、大きな処理が走っている最中に別の指示を出した場合、その新しいタスクは「waiting(待機中)」状態としてリストに追加表示され、先行タスクが終わると自動で「running(実行中)」に切り替わる様子がUI上で確認できます。Viewerのおかげで、ターミナル上で進捗ログを追わなくても、Web UIから全タスクの状況を俯瞰できるようになっています。
タスクステータス(running/waiting等)の種類と意味:各ステータスの定義と状態遷移を解説
OpenCode Viewerが表示するタスクステータスにはいくつかの種類があります。主なステータスとしては、現在処理中であることを示すrunning、キューに入り待機しているwaiting、正常終了したcompleted、エラーなどで途中終了したfailedがあります。Viewerのタスク一覧やバッジにはこれらのステータスが各タスクごとに表示され、例えば実行中のタスクがある場合は「running」のラベルやアイコンで強調表示され、まだ開始されていない次のタスクには「waiting」の表示が付きます。一連のタスクが全て完了すれば「completed」となり、異常終了すれば「failed」と表示されます。これらのステータス表示により、ユーザーはバックエンドで何が起こっているのかを正確に把握でき、複数タスクの実行状況も混乱することなく監視できます。
OpenCode Viewerでタスクを中断(Abort)する方法:UIから実行中プロセスを停止する手順
OpenCode Viewerから実行中のタスクを中断(Abort)する操作も簡単に行えます。UI上で現在実行中のタスクには「Abort」ボタン(または停止アイコン)が表示されており、ユーザーがそれをクリックするだけで中断要求が送信されます。例えば、コード生成の処理が思いのほか時間がかかっている場合でも、ブラウザ上のAbortボタンを押せば即座にその処理を停止させることができます。このときバックエンドでは該当タスクに対応するOpenCode CLIプロセスをkillし、タスクの状態は「failed」もしくは中断扱いで終了します。Abort操作は一時停止ではなく完全停止ですが、セッション自体は残るため、必要であれば後で続きを再開することもできます。従来はターミナルでプロセスIDを探してkillコマンドを叩くような手間がありましたが、Viewerによりワンクリックで安全にタスク中断が行えるようになりました。
タスク中断機能の内部処理と即時反映:Abort要求送信とSSEによるUI更新の仕組みを詳しく解説します
Abortボタンが押されると、バックエンドでは直ちに対応するAPI(/tasks/abort
)が呼び出され、タスク中断の内部処理が実行されます。前述のOpencodeTaskController内の該当プロセスに対してkillシグナルが送られ、OpenCode CLI側の処理が停止します。同時に、タスクコントローラは中断が完了した旨のイベントを発行し、SSE経由でフロントエンドに通知します。その結果、ブラウザのUI上でもほぼリアルタイムに当該タスクがリストから消えるかステータスが「failed/aborted」状態に更新され、ユーザーは処理が停止したことを即座に確認できます。この一連の流れは数秒とかからず実行され、ユーザーが中断操作を行ったらすぐにUIに反映されるため、ストレスなくタスク制御が可能です。
中断機能を利用する際の注意点と再開方法:Abort後にセッションを再開する手順と留意事項を詳しく解説
タスク中断機能を使う際にはいくつか留意すべき点もあります。まず、中断したからといってセッション自体が削除されるわけではなく、単に現在の操作が停止するだけです。そのため、Abort後に同じセッションで別のメッセージを送れば対話を再開できます(対話履歴は保持されています)。逆に、実行中の処理を強制終了することで、一部の操作が中途半端な状態で止まる可能性もあります(例: ツールがファイルを書き込み途中だった場合など)。もっともOpenCode Viewerは基本的にOpenCode CLIプロセスをkillするだけなので、OpenCode側でロールバック等が必要なケースは想定されていません。また、中断操作は即時に反映されますが、処理内容によっては停止まで数秒かかる場合もあります。Abortを実行したのにタスクがすぐ消えないと感じたら、少し待ってみると良いでしょう。いずれにせよ、この機能によりユーザーは不要な待ち時間を最小限に抑えつつ必要なときだけ処理を走らせるという柔軟な運用が可能になります。
Git統合で差分確認:ブランチ・コミットの可視化と未追跡ファイルを含むDiff機能の使い方を徹底解説
OpenCode Viewerは、AIとの対話履歴だけでなく、その過程で生成・変更されたコードの差分を視覚化するGit連携機能を備えています。これにより、AIがコードを書き換えた場合でも、どの部分がどのように変更されたかをブラウザ上で簡単に確認することができます。
Git連携機能で表示できる情報(ブランチ・コミット一覧):切り替え可能なブランチや履歴を詳しく解説します
Git連携機能を有効にしていると、Viewer上で現在のGitブランチ名や直近のコミット一覧を確認できます。例えばプロジェクトがmain
ブランチ上であれば、その名称が表示され、切り替え可能な他のブランチもリストアップされます。また、最新のコミットメッセージやコミットIDが時系列順に一覧表示され、どのような変更履歴が積み重なっているかを俯瞰できます。UI上でブランチやコミットを選択すれば、その状態に応じた差分を閲覧するモードに切り替わるため、コードベースのバージョン履歴とAI対話の関係性を容易に追跡できます。
ファイル差分ビューアでの変更点ハイライト:追加・削除箇所の色付けと行番号などUI上の差分表示を詳しく解説します
Viewerのファイル差分ビューアでは、ソースコードの変更箇所が分かりやすくハイライト表示されます。具体的には、差分において追加された行は背景が緑色、削除された行は赤色に着色されるため、どの部分がどう変更されたかが一目瞭然です。また、各行の左側には元の行番号と新しい行番号が表示され、編集箇所の位置を正確に把握できます。複数ファイルにまたがる差分も、ファイルごとにセクション区切りされて表示されるため、大規模な変更セットでも全体を見通し良く確認可能です。こうした視覚的ハイライトと情報表示によって、AIが生成・編集したコードの内容を効率的にレビューできる環境が整えられています。
未追跡ファイルの差分表示(人工Diff生成)の仕組み:バージョン管理外の新規ファイルをDiffに含める方法
通常のGitツールでは、新規ファイル(まだgit add
されていないファイル)は「未追跡ファイル」として内容が表示されません。しかしOpenCode Viewerでは、そうした未追跡ファイルの差分表示にも対応しています。Viewerの差分ビューアでは、未追跡の新規ファイルについてもファイル名が一覧に含まれ、その中身の全行が「追加行」としてマークアップされて表示されます。一行一行が緑色の追加行扱いとなることで、新しいファイルにどんなコードやテキストが含まれているかを確認できます。この機能によって、まだGit管理下に置いていない変更であっても見落とすことなくレビューに組み込めます。OpenCode Viewerなら、AIが生成した新規ファイルでさえも他の変更と併せて一元的に差分チェックできるのです。
OpenCode ViewerからGit差分を活用する手順:コードレビューで変更内容を確認する流れを解説
OpenCode ViewerでのGit差分機能は、AIとの対話結果をコードレビューに活用する際に非常に有用です。例えば、AIがプロジェクト内の複数のファイルを編集・生成した場合、対話が一段落した後にViewerの「Diff」ビューを開くだけで、その対話によるコード変更箇所をまとめて確認できます。通常であればgit diff
コマンドを手動で実行してターミナル上で差分を確認したり、IDE上で各ファイルの変更を開いたりする必要がありますが、Viewerなら対話履歴を見終えたその同じ画面で差分確認まで完結します。差分ビューアでは変更点を確認しながら不要な変更がないかチェックしたり、次にコミットすべき内容を検討したりできます。このように、OpenCode Viewerの中でそのままコードレビュー的な確認作業が行えるため、AI駆動のコーディングフローがよりスムーズになります。
Git統合機能を使うメリットと活用シーン:差分可視化による品質向上やレビュー効率化を詳しく解説します
OpenCode ViewerのGit統合機能を活用することで、AIが関与したコード変更のレビュー品質と効率が大幅に向上します。差分を視覚的に確認できるため、AIが生成したコードに予期せぬ改変がないか、人間の目でしっかり検証できます。特に未追跡ファイルまで含めた差分可視化により、AIが新規に作成したファイルや内容も漏らさずチェック可能です。これは、コードレビュー工程での見落としを防ぎ、ソフトウェア品質の維持に寄与します。また、Viewer上で対話履歴と差分を行き来しながら確認できるため、「この変更はどのやり取りで行われたか」といった文脈も踏まえてレビューできる利点があります。結果として、AIアシスタントを活用した開発サイクルにおいて、OpenCode Viewerは安全性と生産性の両面で大きなメリットをもたらします。
ファイル補完APIでパス入力支援:対話時のパス入力を便利にする自動補完機能の仕組みと使い方を詳しく解説
OpenCode Viewerには、対話中にファイルパスをスムーズに入力できるよう支援するファイル補完APIが組み込まれています。大規模プロジェクトで多数のファイルを扱う場合でも、この機能により目的のファイルパスを簡単に見つけて入力することが可能です。
ファイル補完APIの概要と役割:対話の入力中に利用可能なファイルパス候補取得APIを詳しく解説します
OpenCode Viewerのファイル補完APIは、ユーザーが対話入力中にファイルパスを入力する際に候補を提示するためのものです。その役割は、指定されたディレクトリ配下に存在するファイルやフォルダ名のリストを返すことで、ユーザーが正確なパスを簡単に補完できるようにすることです。例えば「/src/comp
…」と入力し始めると、/src/
ディレクトリ内の「comp」で始まるファイル・フォルダが候補としてずらりと表示されます。このAPIにより、ユーザーは長いパスを一字一句タイプしなくても、途中まで入力したら後は候補から選ぶだけで済みます。複雑なディレクトリ構成のプロジェクトでも、パス入力ミスを減らし、対話操作を円滑にする重要な役割を果たしています。
OpenCode Viewerにおけるパス入力支援の仕組み:入力中のパスに応じて候補をリアルタイム表示
OpenCode Viewerでは、ユーザーが対話メッセージの入力欄で/
から始まるファイルパスを打ち込み始めると、それに応じてパス入力支援の仕組みが動作します。内部的には、ユーザーの入力するたびに一定のタイミングでファイル補完APIへリクエストが送られ、現在入力中のパスのディレクトリ以下に存在するファイル・ディレクトリ名の一覧が取得されます。取得した候補リストは入力欄の下にドロップダウン表示され、ユーザーはキーボードやマウスで選択することで残りのパスを自動入力できます。このリアルタイムな候補提示により、深いパス階層の指定や長いファイル名の入力も素早く正確に行えるようになっています。
ファイル補完APIのエンドポイントとパラメータ(basePath):GETリクエストURLとベースパス指定
ファイル補完APIはHTTPのGETエンドポイントとして提供されており、パラメータとしてbasePath
(補完対象とするディレクトリのパス)を受け取ります。例えば、/src
ディレクトリ以下の候補が欲しい場合、GET /projects/:projectId/file-completion?basePath=/src
というリクエストがViewerバックエンドに送られます。これに対し、サーバーは/src
直下に存在するファイル名・フォルダ名のリストをJSON形式で返します。返されるデータにはそれぞれがファイルなのかディレクトリなのかの種別情報も含まれており、フロントエンドではそれを元にアイコン表示を変えるなどのUI上の工夫が可能です。basePath
パラメータを変化させながらAPIを呼ぶことで、任意のディレクトリ階層の内容を逐次取得できる仕組みになっています。
対話中に候補ファイルパスを表示する手順:ユーザー入力欄での自動補完利用方法と流れを詳しく解説します。
対話中にファイルパス補完を活用する手順は直感的です。ユーザーがメッセージ入力欄でパスを入力し始めると、前述のように候補一覧が表示されます。例えば/src/ut
まで入力した時点で、その下にあるutils/
ディレクトリやutil.py
ファイルなどが候補に現れます。ユーザーはキーボードの矢印キーで候補を選択し、Tabキーやエンターキーを押すことで、その候補で自動補完が確定します。すると入力欄のテキストが選択したファイル/ディレクトリ名で補完され、続けて残りのパスやファイル名を入力できます。これらの補完操作は対話の途中でもスムーズに行えるため、長いパス指定によるタイポ(入力ミス)を防ぎつつ、効率よく正確なコマンドやリクエストをAIに送ることができます。
ファイル補完機能を利用する際の注意点(パフォーマンスなど):大規模プロジェクトでの応答速度とセキュリティ
ファイル補完機能を利用する際には、いくつか留意すべき点もあります。まず、大規模なディレクトリを対象にすると、候補一覧の取得に時間がかかる場合があります。特に何千ものファイルが存在するフォルダ配下で補完を呼び出すと、すべての名前を列挙するのにそれ相応の処理時間が必要となり、候補表示がわずかに遅れることがあります。また、補完候補はプロジェクト内のパスに限定されており、ユーザーの権限でアクセス可能な範囲のみが対象です。セキュリティ上、Viewer自身が不必要なディレクトリを参照したりはしない設計ですが、公開された環境で利用する場合にはパス情報が露出しないよう注意も必要でしょう。全体として、この機能は正しく使えば開発効率を高めてくれますが、非常に大規模なプロジェクトでは補完応答が一瞬遅れる可能性がある点を頭に入れておくとよいでしょう。