最近、SwiftでAI支援のツールをいくつも作るようになり、同じような問題に何度も突き当たっていました。
SwiftからLLMを呼ぶこと自体は簡単です。
難しいのは、その周りのワークフローを分かりやすく、保守しやすい形に保つことです。
本当に難しくなるのは、その機能が実際のシステムになったときです。プロンプト、構造化出力、リトライ、ストリーミング、ツール、リトリーバル、メモリ、テスト、そしてAppleプラットフォームのアプリとして自然に振る舞うUI。
そこで作り始めたのが Shikisha です。macOSとiOS向けに、LangChain風のワークフローをSwiftらしく構築するためのライブラリです。まだ早い段階で、現在は 0.1.0 ですが、まわりに例を書いて試すだけでなく、実際のプロジェクトで使う段階まで来ました。
問題はグルーコードだった
たいていのLLMのデモは、まっとうなところから始まります。いくつかメッセージを送り、テキストを受け取り、答えを表示する。
おもちゃのチャットボットならそれで十分です。でも、私が作ってきた種類のツールには足りません。
たとえば JPResume は、英文レジュメを日本式の履歴書と職務経歴書に変換します。そこでモデルは役立ちますが、役立つのは特定の箇所だけです。可能なところでは決定論的なパースをしたい。ステージの間で検証したい。モデルからは、それらしく見える段落ではなく、構造化されたJSONを返してほしい。会社に送るかもしれないPDFになる前に、途中の生成物を確認したい。
ツールにそうした制約があると、モデル呼び出しはより大きなシステムの中の一つのステップになります。
Shikisha 以前も、そのシステムをSwiftで作ることはできましたが、プロジェクトごとに小さなグルーコードの山を抱えていました。
- 使い捨てのプロバイダーラッパー
- 手書きのJSONパース
- その場しのぎのリトライ処理
- 重複したストリーミングのアダプター
- テスト用の個別のモック実装
どれも単体では難しくありませんが、新しいプロジェクトのたびに、また一からやり直す感覚になっていました。
共通のワークフローの形があれば、それらの部品は、プロジェクトごとの足場ではなく、組み合わせ可能なパーツになります。
小さなチェーン、RAGパイプライン、ツールを使うエージェント、アプリのUI。これらすべてで、同じ基本的な語彙が使えるようにしたかったのです。
LangChain のアイデアに、Swiftらしい形を
Shikisha は LangChain からアイデアを借りていますが、実装は単なる移植ではなく、Swiftに合わせて設計しています。
AIツールのエコシステムの多くはPythonを前提としています。実験やバックエンドのサービスにはそれでうまくいきますが、iOS/macOSアプリでは、やがてワークフローが SwiftUI、Structured Concurrency、アプリの状態、テスト、サンドボックス、プラットフォーム固有のAPIと共存する必要が出てきます。
また、別途Pythonのオーケストレーション用バックエンドを前提とするのではなく、Apple向けアプリの中に直接置けるワークフローがほしかったのです。
それが、Swiftでほしかった部分です。
LLMのワークフローを、横に後付けした別のスクリプト層ではなく、普通の型付きのアプリケーションコードのように感じさせる方法です。
中心となるアイデアは、ひとつのプロトコルです。
public protocol Runnable<Input, Output>: Sendable {
associatedtype Input: Sendable
associatedtype Output: Sendable
func invoke(_ input: Input) async throws -> Output
}
プロンプトテンプレート、チャットモデル、出力パーサー、リトリーバー、そしてチェーン全体まで、すべてが Runnable になれます。つまり、単純な「プロンプト→モデル→パーサー」のパイプラインを、上から下へ読める形で書けます。
let chain = ChatPromptTemplate.fromTuples([
.system("Answer concisely."),
.human("{question}")
])
.pipe(model)
.pipe(StringOutputParser())
let answer = try await chain.invoke(["question": "What is Swift Concurrency?"])
大事なのは演算子ではありません。コントラクトです。
プロンプトがメッセージを生成し、モデルがメッセージを受け取るなら、その接続をコンパイラが検査できます。パーサーが AIMessage を期待するなら、モデルはそれを返さなければなりません。チェーンが動けば、それを呼び出し、バッチ実行し、リトライし、コールバックで包み、あるいはフェイクのモデルでテストできます。どれも、より小さな部品とまったく同じやり方でできます。
flowchart LR
prompt[Prompt template]
model[Chat model]
parser[Output parser]
tools[Typed tools]
memory[Memory]
stateGraph[StateGraph]
callbacks[Callbacks]
prompt --> model --> parser
model --> tools
tools --> model
model --> memory
memory --> model
parser --> stateGraph
callbacks -.-> model
callbacks -.-> tools
callbacks -.-> stateGraph
Shikisha は、2026年に当然手に取るであろうSwiftの道具立ても使っています。Structured Concurrency、Sendable な型、AsyncSequence によるストリーミング、プロバイダーのペイロード用の Codable な形、そして通常のインストール経路としての Swift Package Manager です。
いまのところ含まれているもの
現在のリリースは、私が繰り返し必要としてきた部品をカバーしています。
モデルとプロンプト
- OpenAI、Anthropic、Google Gemini、Ollama のチャットモデルアダプター
- プロンプトテンプレート
- 構造化出力のヘルパーを含む出力パーサー
リトリーバルとインデックス
- ドキュメントローダー、テキストスプリッター、埋め込み（エンベディング）、ベクトルストア
- RAG向けのリトリーバー（ベクトル、BM25、ハイブリッド、MMR、マルチクエリ、親ドキュメント、時間加重、セルフクエリ、文脈圧縮など）
- 変更されたドキュメントのために毎回すべてを再エンベディングせずに済む、インクリメンタルなインデックス更新
エージェントとワークフロー
- 会話のためのメモリ
- 型付きのツールと、ツール呼び出し型のエージェントループ
- 循環的・状態を持つワークフローのための
StateGraph
可観測性とテスト
- トレース、使用量、コスト追跡、その他の副作用のためのコールバック
- オフラインのサンプルやテストのための
FakeChatModel とローカルの埋め込み
一覧にすると大きく見えますが、役に立つのは、これらの部品が同じ形を共有していることです。RAGのチェーンと、ひとつの質問をする基本的なプロンプトは、別世界ではありません。同じ少数のアイデアの、並べ方の違いにすぎません。
APIキーなしで、サンプル一式を実行できます。
swift run ShikishaExamples
swift run ShikishaExamples basicChain
swift run ShikishaExamples ragPipeline
テストやデモは、検証対象がワークフローそのものであるなら、稼働中のプロバイダーに依存すべきではありません。
ドキュメントもプロジェクトの一部
最近、本格的な DocC のドキュメントとチュートリアル を追加しました。これでプロジェクトの感触が変わりました。
ドキュメントには、LLMアプリのパターンに不慣れなSwift開発者向けの概念ガイドに加えて、チャットモデル、プロンプト、出力パーサー、構造化出力、ドキュメント、埋め込み、リトリーバー、メモリ、エージェント、グラフ、インデックス、可観測性、回復力（レジリエンス）といった機能ごとの記事を用意しました。
チュートリアルはより実践的です。次のものを作る手順を追っていきます。
- メモリ付きのストリーミングチャットボット
- 自分のドキュメントから答えるRAGアプリ
- ツールを使うエージェント
- ファイル操作ツールを備えた小さなコーディングエージェント
- そのエージェントを組み込んだユニバーサルなSwiftUIアプリ
コーディングエージェントのチュートリアルは、このフレームワークをSwiftでほしかった理由のよい例です。AIのコーディングアシスタントは、驚くほどの部分が、モデルと少しのファイル操作ツールとループだけでできています。もちろん細部は重要です。サンドボックスのパス、型付きのツール引数、ツールの仕様、メモリ、コールバック、そしてモデルがいつ動いてよいかの判断。ですが、それらの部品に名前がつけば、ワークフローは考えやすくなります。
エージェントのループでさえ、読める程度に小さく収まります。
let agent = ToolCallingAgent(
model: model,
tools: [readFileTool, editFileTool],
maxIterations: 8
)
let result = try await agent.run([
SystemMessage(content: "You are a coding assistant working in this project."),
HumanMessage(content: "Summarize the TODOs in this project.")
])
コマンドラインでの実験から SwiftUI アプリへ移るときも、頭の中のモデル全体を別の言語で書き直さずに済むようになります。
すでに使っているところ
JPResume は、Shikisha が自然に収まる最初の公開プロジェクトです。
レジュメのパイプラインには、モデル呼び出し、構造化出力、検証、そして見直せる中間ファイルが必要です。Shikisha を使うと、各ステージがそれぞれ独自のプロバイダーラッパーやパーサーの流儀を持たなくても、それらのステージをより整理された形で表現できます。とはいえ、難しいプロダクトの判断、たとえばモデルにどこまで推測を許すか、検証をどれだけ厳しくするか、といったことは消えません。あくまで、ワークフローによりよい土台を与えてくれるだけです。
もう一つ、あとで書く予定の別のプロジェクトでも Shikisha を使っています。そのプロジェクトは、ライブラリの別の側面を試すものでした。エージェントの振る舞い、ツール、アプリへの統合です。まだ説明できる段階ではありませんが、Shikisha が一つのレジュメツールだけに合わせた形になっていないか、という二つ目の確認として役立っています。
抽象化が本当に機能しているか分かるのは、たいていその瞬間です。最初のデモが動いたときではなく、同じ抽象化が、異なる圧力のかかる二つ目のプロジェクトを生き延びたときです。
まだ早いと感じるところ
Shikisha は成熟したエコシステムではありません。まだ若いSwiftパッケージで、実際のユースケースがはっきりしてくるにつれて、APIはまだ動くかもしれません。
従来のやり方のままで十分な場面もあります。ボタンひとつの裏でプロバイダーを一回呼ぶだけなら、フレームワークを足すのは、その機能に見合わないほどの構造かもしれません。小さな URLSession の直接呼び出しが正解、ということもあります。
Shikisha が意味を持ち始めるのは、ワークフローが呼び出し以上のものになったときです。繰り返し使えるチェーン、リトリーバル、構造化出力、ツールの実行、メモリ、トレース、リトライ、ストリーミング、あるいはプロバイダーに当てずに走らせたいテストが必要になったときです。
すべてのAI機能を凝って見せたいわけではありません。凝った機能を、より壊れにくくしたいのです。
何が変わったか
私にとって面白いのは、Shikisha がモデルを呼べることではありません。
同じ抽象化が、いまや次のすべてを通して生き延びていることです。
- コマンドラインでの実験
- SwiftUI アプリ
- リトリーバルのパイプライン
- 型付きのツール実行
- ローカルでのテスト
ライブラリが、単なるデモではなくインフラになり始めるのは、その地点です。
ドキュメントはこちらです。
krisbaker.com/Shikisha/documentation/shikisha
リポジトリはこちらです。
github.com/KristopherGBaker/Shikisha
Swiftでアプリを作っていて、Appleプラットフォームのツールチェーンから離れずにLLMワークフローを足すことに興味があったなら、Shikisha が私の現時点での答えです。まだ早い段階ですが、すでに単なる実験という段階は過ぎています。
]]>
