オープンソースAGPL-3.0一行残らず、読めます。
iOS・Android・ウェブの完全なクライアントを、AGPL-3.0-or-later で公開しています。アカウントもサブスクも不要、こちらへ何かを送り返す仕組みもありません。読んで、変えて、自分でホストしてください。
$ git clone https://github.com/oriveo/oriveo.git $ cd oriveo
# Web · Node 22.22+ $ cd web && npm install $ npm run dev:app # localhost:3001
# iOS · Xcode 26, iOS 18+ $ open ios/Oriveo/Oriveo.xcodeproj
# Android · JDK 21 + Android SDK $ cd android && ./gradlew :app:assembleDebug
リポジトリにビルド済みの成果物は含まれません——APK も .ipa もありません。コミュニティ版は、自分でビルドするソースコードです。
リポジトリの中身
iOS · SwiftUI
SwiftUI の画面に UIKit のトランスクリプト、保存は GRDB。Xcode 26 でプロジェクトを開き、Signing で自分の Team を選べば、自分の端末で動きます。
Android · Compose
Jetpack Compose、Room、Koin、Ktor、OkHttp。JDK 21 と Android SDK があれば、assembleDebug 一発でビルドできます。
Web · Next.js
Next.js App Router、React、Zustand、TypeScript。プロジェクトで唯一サーバーを持つ部分ですが、キーもメッセージも保存しません。
macOS · 開発中
ネイティブの macOS クライアントは開発中で、このディレクトリに入る予定です。土台となる Swift の通信レイヤーはすでに書かれ、テストされています。
「プロバイダーをどう呼ぶか」を 3 つのクライアントがそれぞれ実装すれば、いずれ食い違います。shared/ はその振る舞いをデータとして書き下ろしたものです——capabilityrecipe がリクエストの組み立て方を、model-contracts がクライアントに許される動作を定義し、test-fixtures は記録された実際のレスポンス、OriveoProviderKit は Swift 6.1 の通信カーネルです。3 つのクライアントは同じ JSON に対して検証します。
ひとつのコードベース、2 通りの動かし方
3 つのクライアントは同じソースです。違うのは、アカウントとクラウド同期、そして私たちが費用を負担するモデルだけです。
| 機能 | コミュニティ版 | 公式 Oriveo |
|---|---|---|
| ソースコード | AGPL-3.0-or-later | 商用ビルド |
| 自分のプロバイダーキーでチャット | 対応 | 対応 |
| Relay とローカルモデルサーバー | 対応 | 対応 |
| ノート・フォルダー・Skills・添付ファイル | 対応 | 対応 |
| 端末内の支出トラッキング | 対応 | 対応 |
| アカウント | Oriveo アカウント | |
| 保存先 | 端末内。書き出しと復元は手動 | ローカル優先＋デバイス間クラウド同期 |
| Usage Insights と予算アラート | 対応 | |
| Oriveo が費用を負担するモデル（Oriveo AI / Oriveo Free） | 対応 | |
| アナリティクスとクラッシュレポート | 対応 |
コミュニティ版のビルドは ai.oriveo.community から始まる識別子を使うため、同じ端末でストア版と並べて置いても、キーチェーンやローカルデータを共有しません。
今いる場所から始める
Issue を拾う
バグ修正より大きい変更は、まず issue を立ててください。方針の食い違いは、diff の上より issue の上で片付けたほうがずっと安く済みます。
脆弱性は非公開で報告する
セキュリティの問題を公開 issue に書かないでください。GitHub の非公開の脆弱性報告を使うか、件名に SECURITY と入れて [email protected] までメールしてください。数日以内に返信します。
言語を追加する
インターフェースは 16 言語、README も 16 言語あります。訳が読みにくいと感じたときも、言語を足したいときも、プルリクエストを歓迎します。
リポジトリはまるごと clone してください——3 つのクライアントはいずれもリポジトリのルートから shared/ の契約フィクスチャを解決するので、浅い checkout ではテストが通りません。
サービスとして提供するなら、変更も公開してください。
API キーを預かりうるクライアントには、これがちょうどよい制約です。誰かがどこかでホストしていても、その版が実際に何をしているのかを読めるのですから。自分でビルドして自分で使う分には、何の影響もありません。コントリビュートも同じ AGPL-3.0-or-later の条件で受け取ります。