通義千問と DingTalk で OA 承認とチャットの宿題化を自動化する方法

結論から：DingTalk（釘釘）は中国拠点の中小企業で承認と日々の意思決定が実際に行われる場所であり、同時に決定が静かに消える場所でもあります。通義千問（Tongyi Qianwen）は、話し言葉の一文から OA 承認申請の下書きを作り、流れていくグループチャットを担当者付きの番号付き ToDo に変えられます。作るのは下書きまで。提出するのは名前のある人です。

火曜の夜 6 時 40 分、DingTalk のグループで購買の判断が決まります。スレッドには 4 人。うち 2 人は地下鉄で半分だけ読んでいます。そして結論——ノート PC を 12 台、見積 2 番手のベンダーから、下期予算で——は 9 通のメッセージに散らばり、うち 1 通は音声メッセージです。

金曜になっても OA 承認は上がっていません。誰かが忘れたわけでもない。上げるはずの人は「これは確定なのか」が分からず、決めた人は「もう申請は流れているだろう」と思っていた。それだけです。

これは中国拠点の中小企業でもっともありふれた運用の失敗であり、ツールが悪いせいではありません。DingTalk はグループチャットも OA 承認（OA审批）も十分によくできています。ただ、前者を後者に変換することだけは、それ自体ではやってくれない。総務担当者の一週間は、その隙間に消えていきます。

なぜチャットが流れた瞬間に決定が失われるのか

グループチャットと承認申請書は、形の違う二種類のデータです。そして両者を変換する作業は、「これは誰かがやらないといけない」と最初に気づいた人に落ちてきます。

承認申請書が求めるのは構造です。申請者、金額、予算コード、ベンダー、理由、承認ルート。チャットのスレッドにはそのどれもありません。あるのは文脈、ためらい、6 通目での翻意、添付ファイル、そして決定として言明されなかった決定——「行，就这样吧（じゃあそれで）」の一言で、皆は次の話題に移っています。

このズレから三つのことが起こります。修正の対象そのものなので、名前を付けておく価値があります。

• 記録された瞬間がない。議論が決定に変わった地点を示すものがスレッドの中に何もない。同じグループの別の人は、別のメッセージを指します。
• 担当者がいない。参加者 3 人・フォロー担当者ゼロの決定は、フォローされない決定です。承認は自分では上がりません。
• 復元コスト。最後に申請書を書く人は、4 つの項目を埋めるために 40 通を読み返します。実時間 10 分、体感 1 時間。だから後回しになります。

このリストに入っていないものに注意してください。承認ルートそのものと、その背後の経理ルールです。そちらは正常に機能しています。失敗は申請書の手前で起きています。

通義千問は DingTalk の中で何ができるか

通義千問はアリババのモデルファミリーで、Alibaba Cloud のモデルサービス経由で呼び出します。Alicloud 上の他のリソースと同じアカウント、同じネットワークです。すでに Alicloud でホスティングし、日常業務を DingTalk で回している会社なら、このワークフローの両端が同じベンダーの環境に収まります。DeepSeek のサポートボットを越境ではなく Alicloud 上で動かすほうが統制しやすいのと同じ実務的な理屈です。経路が少なく、契約が少なく、データの所在についての議論が二回ではなく一回で済みます。

DingTalk 自体にも AI 機能があり、その内容はエディションによって異なり、時期によっても変わります。何かを作り始める前に、自社テナントで既に何が有効かを確認してください。すでに課金しているものを作り直そうとしている可能性があります。

話し言葉の説明から OA 承認申請の下書きを作る

元が取れるワークフローは地味です。必要なことを普通の中国語で打つか話すかすると、埋まった申請書が返ってくる。それだけです。

「マーケ部にノート PC を 12 台、見積 2 番手のベンダーで、下期予算から」——丁寧に読むと、部門、数量、品目、理由が暗黙に含まれたベンダー選定、予算期間が入っています。モデルはこれを、実際に自社の OA フォームにある項目へ割り当てられます。そして決定的に重要なのは、説明が埋めていない必須項目を教えてくれることです。単価がない。納期がない。どのコストセンターかを誰も言っていない。

価値の大半はこの最後の部分にあります。下書きは便利ですが、三日後に差し戻されるのを防ぐのは「まだ空欄なもの」のリストのほうです。

グループチャットを担当者付きの番号付き ToDo に変える

二つ目の仕事は、出力の形を厳密に指定した要約タスクです。「この議論を要約して」ではありません。それでは誰も動かない一段落が返ってくるだけです。求めるのは三つの独立したリストです。実際に下された決定、担当者と期日の付いたアクション、提起されたまま答えの出ていない未解決の論点。各行に出典メッセージを付けさせます。

この三分割は実務的に効きます。チャットでは決定とアクションが常に混同されますし、「未解決の論点」リストこそが「待って、それ決めてないよね」を引き出す——しかも発注前に、です。

スレッドが裏付けない項目の答えは「記載なし」でなければならず、推測であってはいけません。担当者を創作した ToDo は、リストが無いことより悪い。処理済みに見えるからです。

実務フロー——チャットの議論から追跡可能な承認まで

何をパイプラインに入れるかを決める。すべてのグループではありません。運用上の判断が実際に行われる 2〜3 のグループ——運用、購買、現場——を選び、残りは触らない。雑談グループに要約を向けるとノイズが出て、出力を無視する習慣が育ちます。

継続的にではなく、トリガーで抽出する。誰かが議論の終わりを示すか、毎日決まった時刻に一度動かす。進行中のスレッドを常時要約すると、言い合いの途中を結論として報告します。

三つのリストを同じチャットに戻す。これは見た目以上に重要です。議論が起きた場所に返されたリストは、その場にいた人が数分で直します。個人のダッシュボードに置かれたリストは、誰にも直されません。

生のスレッドではなく、確定した決定から申請書を起こす。決定リストがチャット上で修正されたら、その一行だけを下書きに渡します。40 通ではありません。入力がきれいになり、出力も追跡可能になります。この申請書がどの決定から生まれたかを指させるからです。

名前のある人が確認し、提出する。申請者が項目を確認し、下書きが指摘した空欄を埋め、通常の OA ルートで提出します。承認ルートは一切変えません。ルートこそが統制であり、そのまま残します。

下書きが間違えた箇所を記録する。最初の一か月、モデルが誤って埋めた項目をすべて記録してください。それがプロンプト改善の材料になり、「実際どのくらい使えるのか」と聞かれたときの誠実な答えにもなります。

AI 併用の DingTalk フロー vs 手作業の OA フォーム vs 専用のプロジェクト管理ツール

• AI 併用の DingTalk フロー。仕事がすでに起きている場所から始まるので、定着コストがほぼゼロです。新しいアプリを開いてくれと頼まなくて済みます。10 分の復元作業が 1 分の確認になります。弱点は、上限がチャットの質で決まること。電話で決まって文字に残らなかった判断は存在しないも同然ですし、自信たっぷりに間違った項目はそのまま通されがちです。
• 手作業の OA フォームのみ。「書かれていることは人が意図して打った」という意味では完全に信頼できます。同時に、誰かがフォームを開くと決めることに完全に依存します——そこが壊れる工程です。件数が少なければ十分ですし、失敗の形はエラーではなく沈黙です。だからこそ気づきにくい。
• 専用のプロジェクト管理ツール。Teambition、Feishu のタスク、Jira などは本物の状態——担当、ステータス、履歴——を持ちます。チャット上のリストには決して持てないものです。代償は「人が行くべき場所」が一つ増えること。DingTalk が作業面のすべてである中小企業では、誰も開かないツールは全員が見るチャットのリストより悪い。すでにツールが根付いているなら、チャットではなくそこへ書き出してください。

中小企業にとって正直な組み合わせはこうです。使われているツールがあるなら残す。ないならリストは DingTalk に出す。どちらの場合も、承認ルートは経理が監査できる OA に置いたままにする。

うまくいかないとき

予算コードを間違えた申請書。モデルは文脈からコストセンターを推測し、もっともらしく、自信を持って外します。経理が気づくのは月末で、それは気づくには悪いタイミングです。対策は単純で、推測でコードを埋めさせないこと。原文に文字として現れているか、さもなければ空欄で人に渡すかの二択にします。

静かなスコープ変更。数量が 10 → 12 → 10 と動いたスレッドは、モデルが重く見たほうの数字に要約されます。抽出したすべての数値に出典メッセージを求めれば、確認者は肝心の一通を数秒で確かめられます。

監査証跡がない。AI が起こした申請書が、元になった入力の記録なしに提出されると、その申請が存在する理由そのものが失われます。出典となった決定の一行を申請書と一緒に残してください。理由欄に貼るだけで十分です。

自動提出。抽出・起案・提出まで閉じたくなります。やめてください。チャットと承認ルートの間に人がいない申請は、そのルートを意味あるものにしている唯一の統制を外します。監査で最初に問われるのはそこです。

正しくやるために——承認ルートの統制、データの所在、IT を呼ぶ場面

承認ルートは業務の一工程ではなく財務統制です。何を自動化しても、提出する人と承認する人は人のまま、変えないでください。自動化によって「考える」より「出す」ほうが簡単になったなら、それは処理を速くしながら統制を弱めたということです。しかも、見えない形で。

DingTalk から何が出ていくのかを具体的に。購買スレッドにはベンダー名、価格、社内の予算事情が入っています。何かをモデルのエンドポイントに流す前に、どのエンドポイントか、どの地域か、保持条件はどうかを把握してください。しかも推測ではなく現行の条項を直接確認すること。条項は変わります。通義千問を Alicloud の中国リージョンで動かせば、これらが一つの事業者・一つの法域の中に収まります。この用途で越境 API より優先する主な理由がそこにあります。

認証情報を本番資格情報として扱う。チャットを読み、承認の下書きを作れるモデルの API キーと DingTalk アプリの資格情報は、合わせると「業務会話への読み取り権限」と「経理ワークフローへの書き込み権限」です。ローテーションと責任者のあるシークレット管理に置くべきもので、誰かのノート PC のスクリプトの中ではありません。

アプリの権限は狭く。DingTalk の企業内アプリには広いチャット読み取り権限を与えられます。必要なグループと必要な承認テンプレートだけに絞ってください。レビューで問うべきは「動くか」ではなく「ほかに何が読めてしまうか」です。

どの構成で動かすか、抽出プロンプトと固定の出力構造をどう書くか、忙しい週でも守れる確認ルールをどう決めるか——これは AI+ サポートの仕事です。Alicloud 側——モデルのエンドポイントの位置、ネットワーク経路、鍵の管理者——はマネージド IT クラウドサービス。その下の DingTalk アプリ登録、権限の絞り込み、日々の運用は通常のマネージド IT サポートです。同じ発想の顧客向け版についてはAlibaba Cloud 上で DeepSeek のカスタマーサービスチャットボットを動かすをご覧ください。承認ルートの設計から相談したい場合はお問い合わせください。

よくある質問

このデータが Alicloud のネットワークの外に出ることはありますか

どのエンドポイントを呼ぶかで完全に決まります。Alibaba Cloud の中国リージョンのモデルサービス経由で通義千問を呼ぶなら、リクエストはその事業者と法域の中に留まります。中国拠点の業務でこの組み合わせを優先する具体的な理由がこれです。同じワークフローを海外の API に向ければ、それは越境データ移転であり、付随するすべてが発生します。最初の本番呼び出しの前に、事業者の現行ドキュメントでリージョンと保持条件を確認してください。

AI が起こした承認申請を、確認なしで自動提出できますか

技術的には可能ですが、そう作るべきではありません。承認ルートは財務統制であり、チャットと提出の間に生身の申請者がいることがその意味を保っています。まず起案・確認の工程を作り、下書きの正答率を測り、「効率のために確認者を外す」という主張には抗ってください。得られるのは数分、手放すのはルートが存在する理由そのものです。

DingTalk 純正の AI 機能と何が違いますか

DingTalk はアシスタントや要約系の機能を自社で提供しており、その内容はエディション依存で、製品の進化とともに変わります。作り込む前に、自社テナントに既に何があるかを確認してください。自作する理由はたいてい具体性です。自社 OA フォームの正確な項目、自社の予算コード規則、三分割という出力形式。純正機能で足りるならそちらを使うほうが安く、保守も他人がやってくれます。

一つのグループで複数の議題が同時に走っている場合は

それが通常です。だからこそ抽出は要約ではなくリストを返すべきなのです。独立した決定はそれぞれ別行の番号付きで、と明示的に指定してください。最初のうちは区切り方を直すことになるはずです。モデルは関連する二つの決定を一つにまとめがちです。リストをチャットに戻すことがその検出手段になります。その場にいた人が即座に「2 番と 3 番は別の話」と言ってくれるからです。

すでに DingTalk を使っていますが、Alibaba Cloud は必須ですか

モデルを動かす場所は必要で、そのエコシステムに既にいるなら Alicloud が自然な選択です。同じアカウント、同じネットワーク、一つの法域。ただし必須要件ではありません。重要なのは、モデルをどこで動かすかという判断が、どの境界をデータが越えるのかを理解している人によって意図的に下されることです。いちばん簡単に取れた API キーで決まってしまうのではなく。

項目抽出の精度は実際どの程度ですか

使えるだけの精度はありますが、確認なしで信頼できる精度ではありません。その比率は自社のチャットがどれだけ整っているかで変わります。構造的で意思決定志向のスレッドはよく抽出できます。長く、枝分かれし、音声混じりのスレッドはうまくいきません。生産的なのは、誰かの示す割合を——当社のものも含めて——受け取るのではなく、自社のグループで一か月測ることです。

スレッド内の音声メッセージはどうなりますか

DingTalk のグループで音声は非常に多く、これは実在するギャップです。音声が文字起こしされていなければ、その中身は抽出にとって存在せず、出力のどこにも「欠落があった」とは書かれません。文字起こしを対象に含めるかどうかを早めに決めてください。含めないなら、音声を含むスレッドは「モデルは一部しか読んでいない」ものとして扱い、出力にもそう明記させることです。