注意: 本記事はドキュメント・公開情報をもとにした評価記事です。コード例はシミュレーションです。
3行要約
- Twilio等の高額なSMS APIを使わず、iMessage経由で顧客対応AIを安価に構築できるツール。
- macOS環境に依存する泥臭い自動化を抽象化し、Python SDKでモダンなAIエージェント開発を可能にする。
- Apple IDの利用規約やmacOSの常時稼働というインフラ的制約があり、中〜大規模な商用利用には慎重な設計が求められる。
📦 この記事に関連する商品(楽天メインで価格確認)
Mac mini M2 (16GB RAM)Chertを24時間稼働させるサーバーとして、静音性と省電力、AI処理性能のバランスが最適
※アフィリエイトリンクを含みます
結論から: このツールは「買い」か
結論から言うと、Appleエコシステムに浸かっている個人開発者や、スモールビジネスの顧客体験を向上させたいエンジニアにとって、Chertは「検討に値する唯一無二のツール」です。★4.0評価。
これまでiMessageの自動化は、macOSのchat.dbをSQLiteで直接読み込んだり、AppleScriptを力業で回したりする極めて不安定な実装が主流でした。ChertはこれをAPIレベルでラップし、LangChainやLlamaIndexといった既存のAIフレームワークと接続しやすくしています。
一方で、大量のメッセージ送信によるiCloudアカウントのBANリスクや、ホスティングにmacOSが必須である点は無視できません。Twilioのような「金で解決する堅牢性」を求めるエンタープライズ用途には不向きですが、特定の顧客層に向けたリッチなコミュニケーション手段としては、これ以上の選択肢はありません。
このツールが解決する問題
従来のAIエージェントによる顧客接点は、WebチャットUIか、LINE、あるいはSMS(Twilio経由)が一般的でした。しかし、米国をはじめとする特定の市場ではiMessageのシェアが圧倒的であり、青い吹き出し(Blue Bubbles)で届くメッセージの開封率は他のプラットフォームを凌駕します。
開発者にとっての最大の問題は、Appleが公式に「iMessage API」を公開していないことでした。Twilioを使ってSMSを送れば1通あたり数円のコストがかかり、画像やリッチコンテンツを送るMMSになればさらに跳ね上がります。Chertは、macOS上のメッセージアプリを介して通信をトンネリングすることで、この「APIがない」「コストが高い」という2つの壁を突破します。
実務レベルで言えば、既存のCRMと連携して特定のトリガーでiMessageを送り、その返信をGPT-4oで解析して予約確定まで自動化する、といった流れを数行のコードで実装できるのがChertの真骨頂です。
実際の使い方
インストール
Chertを使用するには、macOS環境(Ventura 13.0以降を推奨)が必要です。LinuxサーバーやWindowsでは直接動作せず、これらがホストとして機能する必要があります。
# Python 3.10以上が必須です
pip install chert-ai
インストール自体は30秒で終わりますが、その後に「アクセシビリティ」や「フルディスクアクセス」の権限をmacOSの設定から付与する必要があります。これを忘れると、スクリプトを実行してもメッセージを読み取れずエラーを吐きます。
基本的な使用例
ChertのSDKは、メッセージの受信をイベントとして捉えるイベントドリブンな書き方が可能です。
import os
from chert import ChertClient
# APIキーと環境設定(事前にダッシュボードで取得)
client = ChertClient(api_key=os.getenv("CHERT_API_KEY"))
@client.on_message
def handle_incoming_text(message):
# メッセージが届いたら中身を確認
sender = message.sender
body = message.body
print(f"Received from {sender}: {body}")
# 簡易的なAI応答ロジック(実際はここでOpenAI等を呼ぶ)
if "予約" in body:
response = "ご予約ですね。空き状況を確認します。"
client.send_message(to=sender, text=response)
# 常時監視モードで実行
client.run_forever()
このコードの肝は、client.run_forever()でmacOS上のメッセージアプリと同期を取り続ける点です。実務ではここに例外処理を入れないと、Wi-Fiの一時的な切断などでプロセスが落ちるため、Supervisor等でのデーモン化が必須になります。
応用: 実務で使うなら
実際の業務では、単純なオウム返しではなく、ユーザーの意図を汲み取ったRAG(検索拡張生成)との組み合わせが求められます。
from chert import ChertClient
from openai import OpenAI
ai = OpenAI()
client = ChertClient(api_key="your_key")
@client.on_message
def smart_support(message):
# コンテキストを含めてAIに投げる
# iMessageから送られてきた画像も message.attachments で取得可能
chat_completion = ai.chat.completions.create(
model="gpt-4o",
messages=[
{"role": "system", "content": "あなたは親切なコンシェルジュです。"},
{"role": "user", "content": message.body}
]
)
reply = chat_completion.choices[0].message.content
client.send_message(to=message.sender, text=reply)
client.run_forever()
iMessageのメリットとして、HEIC形式の画像やPDFなどをシームレスに扱える点があります。ChertのSDKはこれらアタッチメントのローカルパスを返してくれるため、そのままGPT-4o-visionに流し込んで内容を解析させるのも簡単です。
強みと弱み
強み:
- 圧倒的な低コスト: 100通送っても1,000通送っても、iCloudの容量さえあれば送信料は実質無料です。
- 高い開封率: ユーザーの通知画面に直接、信頼性の高いiMessageとして届くため、メールよりも確実に読まれます。
- SDKの抽象化が優秀: macOS内部の複雑なDB監視や権限周りの処理を隠蔽しており、エンジニアはAIロジックに集中できます。
弱み:
- macOSへのハードウェア依存: 本番環境としてMac MiniやMac Studioを常時稼働させる必要があります。クラウド(AWSのMacインスタンスなど)はコストが高すぎて本末転倒です。
- 日本語情報の不足: ドキュメントはすべて英語であり、マルチバイト文字(日本語)のエンコーディング周りで稀に挙動が不安定になる場面があります。
- アカウント停止のリスク: 大量のスパム的な送信を行うと、Apple IDそのものが停止される可能性があります。これはビジネスにおいて最大の致命傷になり得ます。
代替ツールとの比較
| 項目 | Chert | Twilio (SMS) | SendBlue |
|---|---|---|---|
| 送信コスト | ほぼ無料 | 従量課金(高い) | 月額定額+従量 |
| 実行環境 | macOS必須 | どこでも可 | クラウドAPI |
| セットアップ | やや難(権限設定) | 容易 | 容易 |
| 到着率 | 非常に高い | キャリアフィルタあり | 高い |
Twilioは確実に届きますが、コストが課題です。SendBlueはChertに近いサービスですが、APIを介して独自のインフラでiMessageを送るため、自由度とコストの面でChertの方が「自分で組めるエンジニア」には向いています。
料金・必要スペック・導入前の注意点
Chert自体の利用料金は、現在Product Huntでのリリース直後のため、一部無料枠がありますが、本格的な商用利用は月額$20〜のサブスクリプションが想定されています。
導入前に必ず用意すべきなのは、M1/M2以降のチップを搭載したMacです。Intel Macでも動作しますが、AI処理(ローカルLLMを動かす場合など)のパフォーマンスを考えると、ユニファイドメモリを16GB以上積んだMac Miniが最もコスパの良い「iMessageサーバー」になります。
また、個人のApple IDをそのまま使うのは避けましょう。万が一のBANに備え、業務専用のApple IDを新規作成し、その番号でのみ通信するように設定を分けることが実務上の鉄則です。
私の評価
私はこのツールを、特定の業種——例えばパーソナルジムの予約管理や、高級不動産の案内など、1対1の密なコミュニケーションが価値を生むプロジェクトで採用します。
★4.0とした理由は、iMessageという「アンタッチャブルだった領域」を、現代的なPython SDKの形に落とし込んだ開発者の執念を評価したからです。一方で、Appleの規約という薄氷の上を歩くようなツールであることも事実です。
「誰が使うべきか」で言えば、macOSをサーバーとして運用することに抵抗がなく、Twilioの請求額に頭を抱えているエンジニアです。逆に、「インフラはすべてクラウド(Linux)で完結させたい」という人や、SLA 99.99%を求める大規模サービスには全く向きません。
よくある質問
Q1: iCloudアカウントがBANされる可能性はありますか?
はい、十分にあります。短時間に数百通の未登録番号への送信、ユーザーからの「迷惑メールとして報告」が重なると、アカウントが停止されます。人間らしい送信間隔を設けるなどの対策が必須です。
Q2: Linuxサーバー(Ubuntu等)で動かす方法は?
ネイティブでは動かせません。どうしてもという場合は、自宅にMac Miniを置き、そこからWebhookでLinuxサーバー上のメインシステムと連携させる「ハブ」としての運用が現実的です。
Q3: 日本の電話番号でも使えますか?
iMessageとして有効化されている電話番号、またはApple ID(メールアドレス)であれば問題なく利用可能です。キャリアメールではなく、iMessageの設定が完了していることを確認してください。






