【iOS 27】現場で話した1日の作業を日報の要約にする機能を作って、iPhone 15 Proで測ってみた

こんにちは。リテールアプリ共創部で事業企画を担当しているかめだです。

別記事で、建設現場の写真を日報にする（現場で撮って、現場で書き終える）を書きました。朝礼の黒板やホワイトボードの写真から、日報の作業内容や人員配置の下書きを作る設計です。その後に書いた【iOS 27】パスポートと免許証を撮って宿泊者名簿の下書きにする機能を作って、iPhone 15 Proで測ってみたで、写真の文字を1字ずつ写す業務は端末内のAIモデルではなく文字認識の範囲だと分かりました。

そこで今回は、黒板の写真の読み取りは測らず、日報の要約というモデルだけを取り出しました。現場の担当者がその日の作業を話した内容から、日報に載せる要約を作る機能を作り、iPhone 15 Proの実機で測っています。

先に、前回の仮説への答え

前回の記事で書いたことのうち、今回測れた範囲で答えます。

現場担当者が話した1日の作業から、日報の要約を作るところは、Apple Intelligenceの端末内モデルに任せられます。 ただし合格ぎりぎりで、聞き取りミスの多くは音声認識の聞き違いが原因でした。モデル自身は話していない数値を作りませんでした。前回の記事の設計のうち検証できたのは、話した内容から要約を作る部分だけです。

欄に分けて1文ずつ書かせ、あとでつないだ

さて、作業内容・人員・安全・変更や遅れ・翌日の予定の5つの欄を用意し、欄ごとに短い1文を書かせて、アプリ側でつなげる作りにしました。

@Generable
struct ConstructionSummary {
    @Guide(description: "その日の作業内容を、数量も含めて1文・30字以内で。数値は話したとおりの数字で書く")
    var work: String

    @Guide(description: "人員を1文・15字以内で。話していなければ「記載なし」")
    var crew: String

    @Guide(description: "安全に関すること（けが、ヒヤリとしたこと、ガスや酸素の測定、取った対策）を1文・25字以内で。なければ「特になし」")
    var safety: String

    @Guide(description: "予定からの変更、遅れ、中断と、その理由を1文・30字以内で。なければ「特になし」")
    var issues: String

    @Guide(description: "翌日の予定を1文・20字以内で。話していなければ「記載なし」")
    var next: String
}

エンジニアではない私でも、型を決めて渡すだけでここまで作れました。

呼び出しは1回です。話した内容の書き起こしをそのまま渡し、この型で受けます（Apple Intelligence でアプリづくりは何が変わるのか（AFM 3 の全体像））。

let r = try await session(constructionInstructions).respond(
    to: "次の話から、日報の要約を作ってください。\n\n\(text)",
    generating: ConstructionSummary.self,
    options: GenerationOptions(maximumResponseTokens: 220))

指示文には「話に出てこない事実や数値を足しません。数値は話したとおりの数字で書きます。計算して新しい数を作りません」と書きました。「作業員10人、オペレーターを入れて11人」という話から「オペレーター1人」を引き算して書いたことが一度あり、この一文を足すと消えました。

モデルに任せたのは、話のどの部分が作業・人員・安全・変更・予定かを決めて、欄ごとの1文にまとめることです。ルールに任せたのは、欄の文を最初の句点で切ること、出力の上限（maximumResponseTokens: 220）、空の欄（「記載なし」「特になし」）を除いてつなげることです。

5つの欄は最初からあったわけではありません。事前の試しの1回目は、1本の要約をそのまま書かせる作りで試したところ、30回中23回が60秒の打ち切りに当たりました。書き続けて止まらなくなります。これは想定していませんでした。なので、欄に分け、出力の上限と、欄ごとに最初の句点で切るルールを足すと止まりました。欄の長さを生成の段階で縛る制約（@Guide の .pattern）も試して、ここで足止めされました。ビルドは通っても実行時に「An unsupported generation guide was used」というエラーになり、使えませんでした。

「変更・遅れ・中断」の欄は、最初は4つの欄だけで実物を測ったあとに足しました。理由は次の節で書きます。

測り方を先に決めた

では、測り方の話です。合格ラインは3つです。元の話にある要点の8割以上が要約に入ること、元の話にない数値を足さないこと（0件）、120字以内であることです。測る前に決めました。

見本は2種類使いました。合成の見本（決まった言い方の原稿10本）と、実物（私がiPhoneに向かって実際に声に出した5本）です。実物の中身は架空の現場の記録で、実在の現場ではありません。言い換えの見本は、この場面では用意していません。

音声はSFSpeechRecognizerで認識しました。requiresOnDeviceRecognition = trueで、通信に出る認識は使っていません。というのも、トンネル内や地下の掘削、山あいの造成地のように、電波が届かない現場があるからです。音声認識もAIモデルも、端末の中だけで動く作りにしました。1本の音声は1回だけ認識し、同じ書き起こしでモデルを3回呼んでいます。

Macの読み上げ機能で合成の見本を音声にして同じように測ると、書き起こしの文字の誤り率が22.5%あり、要点は書き起こしの時点で47.8%、要約で42.0%しか残らず、話していない数値も3件入りました。私の声より大幅に崩れるので、読み上げ音声での結果は参考にとどめ、音声認識を通す条件は実物（人の声）で判断しています。現場の言葉（発破、立坑など）を認識器に渡す設定（contextualStrings）も試しましたが、書き起こしは変わりませんでした。

事前の試しでは、合成の見本10本を各3回、原稿をそのまま渡して測りました。

実物5本で測った結果

私が声に出した5本を、各3回、音声認識にかけて測りました。1回目は、事前の試しで合格した4つの欄の作りのままです。

不合格でした。1件ずつ見ると、不合格の原因は2つに分かれます。

1つ目は、音声認識の聞き違いです。書き起こしの時点で、要点はすでに78/90 = 86.7%しか残っていませんでした。「掘削、発破2回」は「掘削葉っぱに返しております」に、「作業員7人です」は「作業員の人です」に、「立坑の酸素濃度」は「立位の酸素濃度」になりました。人数や現場の固有の言葉が、別の言葉に置き換わります。

2つ目は、モデルの欄以外の言葉です。「資材の搬入が1時間遅れました」という話には入れる欄がなく、3回とも要約から落ちました。作業内容・人員・安全・翌日の予定の4つの欄には、遅れや中断を書く場所がありませんでした。

そこで「変更・遅れ・中断」の欄を足しました。同じ合成の見本10本で測り直すと87.9%で合格しています。実物を見てから直した作りの数字です。同じ実物5本で、もう一度測りました。

合格しましたが、ぎりぎりです。18点の外れのうち12点は聞き違いによる間違いで、1回目と同じ原因が続いています。残り6点はモデルの欄がないことです。「強風で午後1時間中断しました」の「強風」という理由が3回とも落ち、「午後1時間中断した」だけが残りました。「怪我はございません」は3回とも安全の欄で「特になし」になりました。けががないことも日報の事実ですが、モデルは「特になし」にまとめました。

話されなかった数値は、1回目・2回目とも足しませんでした。採点では、実物の書き起こしにある「怪我」を、正解の「けが」と同じ意味の語として数えています。この扱いを足す前は、1回目は65.6%でした。

かかった時間は、モデルの中央値3.40秒、音声認識の中央値0.73秒です。

通信を切った状態でも、同じように動くか？

動きました！電波の届かない現場で使えるかを確かめるため、iPhoneを機内モードにしてWi-Fiも切り、同じ録音データ5本を各3回、改めて測りました。測る直前に、端末がどの通信にもつながっていないことをアプリの中で確かめ、結果と一緒に記録しています（Network フレームワークの NWPathMonitor）。

音声認識の書き起こしは、通信ありのときと5本とも1文字も変わりませんでした。要点の数の差（72と73）は、同じ書き起こしでもモデルの出力が回によって少し変わる分です。所要は、通信なしでモデルの中央値2.53秒、音声認識の中央値0.50秒でした。

話した内容をルールだけで日報の言い方に縮められるか？

ルールだけでは作れないと判断し、今回はルールだけの検証をしていません。要約は、話のどの部分が作業・人員・安全・変更・予定かを決めて、話し言葉を日報の言い方に縮めます。決まった言葉で切り出すルールでは、話す順番や言い方が変わると欄に入りません。数値を足さない・計算しないという制約は指示でモデルに課し、欄の文を最初の句点で切る扱いだけをルールにしました。

この業務で、Apple Intelligence で輝けるか？

輝けますが、合格ギリギリで、聞き間違いの多くは音声認識の聞き違いが原因でした。

モデルは、話のどの部分が作業・人員・安全・変更・予定かを決めて、欄ごとの1文にまとめることです。話していない数値や事実を作らないことも、指示だけで守られました。ルールは、欄の文を最初の句点で切ること、出力の上限を決めること、空の欄を除いてつなげることです。人が確定するのは、前回の記事に書いたとおり現場監督が下書きを確認して確定する段階で、この検証では測っていません。

まだ言えないのは、聞き違いの割合です。今回の実物は私の声5本だけで、話す人が変われば聞き違いの起き方も変わります。通信を切った状態では手元で動くことを確かめましたが、実際のトンネル内や地下の掘削現場で使ったわけではありません。

次に試すこと

次に確かめるのは3つです。実物の件数を増やすこと（今回は私の声5本のみ）。現場監督や職長など、複数の話す人で測ること。1日の作業を数分話すような長い話でも、欄が壊れずに要約になるかを確かめることです。黒板の写真から作業内容・人員配置の下書きを作る部分は、前回の記事の設計のうち今回測っていない残りで、次の検証で扱います。

よくある質問

聞き違いが多いなら、音声認識でなく手入力のほうが確実ではありませんか。

手入力との時間の比べは、まだ測っていません。分かっているのは、聞き違いがあってもモデルが数値を作り足さなかったことです。一方で、聞き違えた言葉は「トンネルの掘削、葉っぱに返す作業」のように要約にそのまま残ります。現場監督が下書きを確認して直す前提は、話して入力しても変わりません。

iPhone 15 Pro以外の端末でも、同じ精度になりますか。

測っていません。今回はiPhone 15 Pro 1台だけで測っています。

長い朝礼の内容も、そのまま要約できますか。

測っていません。今回の実物は1本あたり4文ほどの短い話で、数分に渡る長い話は次に試すことに挙げています。

参考

• Apple Developer Documentation, Foundation Models: https://developer.apple.com/documentation/foundationmodels
• Apple Developer Documentation, requiresOnDeviceRecognition: https://developer.apple.com/documentation/speech/sfspeechrecognitionrequest/requiresondevicerecognition
• Apple公式（WWDC2026）: https://developer.apple.com/videos/play/wwdc2026/241/

同じように、話した内容をApple Intelligenceで日報にする仕組み、現場のiPhoneでぜひ一度試してみてください！

では、おつかめ！

--

クラスメソッドでは、既存スマホアプリをFlutterでiOS/Android同時に作り直し、バックエンドはAWSで再構築する「AI駆動アプリリニューアル」を提供しています。現行アプリの仕様読み解きから設計・実装まで生成AIを組み込んだ開発プロセスで進めるため、レガシー化したアプリのリニューアルを短い期間で作り直します。
サービス詳細・お問い合わせはこちら