メール皆さん使ってますか？
全世界共通のプラットフォームという面ではメールはまだまだ現役ですよね。
今回は共有メールアドレスではなく、個人間のメールの取り扱いについて考えてみたいと思います。
個人メールですが、こんな地獄があると思います。
僕は社会人歴そこそこですが、いまだに慣れません…😢
- CC地獄 🔥
- 共有のためのCC送付で、大量のメールがあふれて、その結果共有が意味をなさなくなる。
- 文脈読解力地獄 🌀
- 並列で違ったメール起点が走っているので、文脈を理解することが難しい。
この地獄を簡易的にすくう蜘蛛の糸を考えてみました
🧵 kintone + 連携コネクタです！
今回は、outlookメール＋kintone連携＋kintone AIの連携を試してみます。
比較的簡単なので、ぜひ皆さんお試しください。
この記事のポイントは、メールを話題ごとにkintoneの同一レコードにいれ、更新することです。
簡単に動作の説明をすると…
- メールがきたら、kintoneに保存。
- 新規メールならレコード追加。
- 既存のやり取り(会話)なら、レコード更新。
こういう動作をさせるだけです。
kintoneとは？
「キントーン」は業務のシステム化や効率化を実現するアプリがつくれるクラウドサービスです。
ノーコードで活用ができますが、APIも準備されていてシステム開発や、関連サービスを作ることも可能です。
💰️記事掲載時点(2026年6月)はお試し環境と開発者環境が提供されています。
連携コネクタとは？
「連携コネクタ」は、Microsoft 365の主要サービスとkintone/Garoonをノーコードで連携するサイボウズのクラウドサービスのオプションです。
つまりGUIで簡単な連携が作れます。
💰️記事掲載時点(2026年6月)はお試し環境が提供されています。
実装
今回はできるだけシンプルに実装してみます。
4つの実装のイメージです。
- メール格納用のkintoneアプリを作成する
- 連携コネクタでOutlookメールの受信を検知する
-
conversationIdで同じ会話か判定する - kintoneへ新規追加または更新する
1：メール格納用のkintoneアプリを作成する
メールの内容が格納されるkintoneアプリを作ります。
構成はかなり簡単。3つのフィールドでOKです。
| フィールド名 (コードは同名) |
フィールドタイプ | 説明 |
|---|---|---|
| 件名 | 文字列(1行) | メールの件名が入ります(随時更新) |
| 本文 | 文字列(複数行) | メールの本文が入ります(随時更新) |
| ID | 文字列(1行) | 会話が一意か判断するIDが入ります。 outlookメールの ConversationIDを入れる想定です。 |
※フィールドコードはフィールド名と同名想定です
2〜4:連携コネクタの設定
今回の連携では、同じメールの会話を1つのレコードに集約したいと思います。
そのため、メール受信のたびに
- 新しい会話ならレコード追加
- 既存の会話ならレコード更新
を行います。
新規/既存メールの判別は連携コネクタで取得できるconversationIdを使い、UPSERTの動作を実装します。
このconversationIdはOutlookのメールオブジェクトのプロパティです。
このプロパティは、アイテムを会話に関連付けます。 これらのアイテムと、会話の ConversationID プロパティで同じ値であります。
https://learn.microsoft.com/ja-jp/office/vba/api/outlook.mailitem.conversationid
また、連携コネクタの全体像は以下の画像の通りです。
STEP 1 (トリガー) メール受信の検知
僕のシナリオでは、簡易的に実装するのでトリガーをメール受信の検知にした上で、差出人を特定の相手のメール受信の検知にしています。
包括してメールをkintoneに連携したい場合、アクション一般のスケジュール実行でもいいと思います。
その場合朝、昼、晩などでメールが共有される仕組みが可能です。
| 項目 | 入力値 |
|---|---|
| イベント選択 | メール受信の検知 |
| フォルダ | 受信トレイ |
| 差出人 | 特にみたいメールアドレス |
STEP 2 レコードの一覧取得
| 項目 | 入力値 |
|---|---|
| アクション選択 | レコードの一覧取得 |
| 基本設定 > 取得方法 | クエリを入力する |
| 基本設定 > クエリ | ID="conversationId" |
| 基本設定 > 取得するフィールド | $id,ID |
※クエリ欄の ID以降の値はダブルコーテーションで囲んでください。
※$idはkintoneのレコードIDです。
STEP 3 配列/表データの件数の取得
| 項目 | 入力値 |
|---|---|
| アクション選択 | 配列/表データの件数の取得 |
| 基本設定 > 件数取得対象 | kintoneレコードの一覧取得の表 |
ここで、STEP 2 の結果の件数を取得します。
つまりゼロなら新規会話ということになります。
STEP 4 シナリオ制御 条件分岐
| 項目 | 入力値 |
|---|---|
| アクション選択 | 条件分岐 |
| 基本設定>条件 | size=0 |
| 基本設定>ブロック | ブロックを開く |
sizeがSTEP 3 で取得した件数です。
新規の会話になっているものがTRUEになります。
ブロックを開くを押すと、TRUE側の動きに飛びます。
ステップ 4.2 kintone レコードの追加(条件分岐 ブロック内)
| 項目 | 入力値 |
|---|---|
| アクション選択 | レコードの追加 |
| アクション選択 | conversationId |
| 基本設定>件名 | subject |
| 基本設定>本文 | content |
ステップ 5 中断判定
| 項目 | 入力値 |
|---|---|
| アクション選択 | 中断判定 |
| 基本設定>条件 | size>=2 |
想定外の重複レコードを検知するため、2件以上の場合は更新せずにシナリオを中断します。
本来conversationIdは一意なので既存のkintone登録は1件しかないはずですが、もし2件以上ある場合はシナリオ自体を中断する処理をいれました。
ステップ 6 繰り返し
| 項目 | 入力値 |
|---|---|
| アクション選択 | 繰り返し |
| 基本設定>繰り返し対象 | kintoneレコードの一覧取得の表 |
| 基本設定>ブロック | ブロックを開く |
STEP 2 kintoneレコードの一覧取得で取得できるのは表形式です。
表形式の値を取得するために、繰り返し処理が必要になります。
たとえ1件のみしか取得していなくても、繰り返しが必要です。
ここが詰まったポイントでした…
詳しくは最後のセクションの詰まったポイントで解説します。
ステップ 6.2 kintone レコードの更新(繰り返しブロック内)
| 項目 | 入力値 |
|---|---|
| アクション選択 | レコードの更新 |
| 基本設定>更新タイプ | レコードID |
| 基本設定>レコードID | $id |
| 基本設定>更新フィールドの指定 | 本文,件名 |
| 更新内容>件名 | subject |
| 更新内容>本文 | content |
以上です。
動作確認
それでは実際に動かしてみます。
今回は以下のようなメールの会話を想定しました。
- サイボウズがフード業者へ、イベント用の食事を発注
- 業者(しんしんフーズ)から代替メニューの提案
- アレルギー表示や温度管理について確認
- 最終的に見積作成待ち
連携コネクタを実行するとkintoneで以下のように格納されます。
下部でサイボウズの担当者がアレルギー表示や、温度管理について質問をし、
業者(しんしんフーズ)から、それについて回答が来ている状態です。
同じconversationIdのメールが1レコードにまとまっていることがわかるかと思います。
このカスタマイズでメールを受信してない人も、メールの内容を確認できるので、以下のようなメリットがでてきます。
- メールを探し回らなくてよい
- 会話単位で状況を追える
- CCに入っていない人でも状況を確認しやすい
レコード一覧分析AIも使ってみる
ここまでで連携自体は完成です。
ただ、せっかくkintoneにメールが集約されたので、
最後に2026年6月にリリースされたkintone AIも試してみます。
今回はkintone AIの「レコード一覧分析AI」を使って状況を整理してみました。
■kintone レコード一覧分析AIへの投げかけ
大規模イベントの進捗教えて
結果は以下のようになりました。
すごくきれいにまとまっていいですね👏
■kintone レコード一覧分析AIからの返答
🍛 メニューの調整状況
当初サイボウズはカレーライス500食を希望していましたが、設備の都合で対応不可となりました。
代替案としてハヤシライスとカレーうどんが提案され、現在検討中です。
✅ 直近の確認事項
・アレルギー表示方法
・温度管理方法
・配布スタッフの有無
🏃♂️ 次のステップ
サイボウズ側の承認後、しんしんフーズが正式見積を作成
「レコード一覧分析AI」の設定方法はこちら
https://jp.kintone.help/k/ja/ai/ai_enable/
まとめ
今回は、連携コネクタを使ってOutlookメールをkintoneへ集約してみました。
実装自体は比較的シンプルですが、
- メールを探し回らなくてよい
- 会話を会話単位で追える
- CCに入っていない人でも状況を把握できる
といったメリットを感じることができました。
また、kintone AIのレコード一覧分析AIと組み合わせることで、
「今何が決まっているのか」「次に誰が動くのか」も整理しやすくなります。
連携というと大規模な業務システム間連携をイメージしがちですが、今回のような小さな情報共有の改善にも十分活用できそうです。
ぜひ皆さんも試してみてください。
おまけ つまったところ
つまったところは以下の通りです。
その1 kintoneの重複禁止フィールド 64文字でつまる
本来は一意である、conversationIdを重複禁止フィールドとしてkintoneに登録し、更新キーにしようとしたのですが…
kintoneの重複禁止フィールドは64文字までしかいれることができませんでした。
連携コネクタのフィールド関数を使い、前後３２文字ずつを取得し、連結するという簡易的な方法をとろうとしたのですが実装として怪しかったのでボツにしました…
その2 連携コネクタのレコードの一件取得でつまる
今回すでにkintoneに格納されているconversationIdを取得するために、ID=conversationIdでレコード一覧取得しています。
一件しかないので、連携コネクタの一件取得を使えばいいのでは？
と思ったのですが、レコードの一件取得はレコードIDでしか取得できません。
kintone REST APIの 1件のレコードを取得するもパラメーターがappとidのみなのでそりゃそうですよね…。
その3 連携コネクタのレコード一覧取得の形式でつまる
連携コネクタの「レコード一覧取得」で取得出来るデータは視覚的な表形式のデータであり、そのままだと値を次のアクションには使えません。使用出来る値としてはnameとcontentという文字列しか含まれていません。
どう値を抽出すれば良いのかでつまりましたが、表形式のデータを次のアクションに使用するためには、「繰り返し」のコネクタを使用する必要があることが分かりました。表の1行目から値を取り出し、次は2行目から、3行目から、というように、表から繰り返しで1行ずつデータを取り出すための処理です。
今回の連携ではレコードの一覧取得で返されたデータは1行しかありませんが、この繰り返し処理を使って値を取得する必要があります。繰り返し処理の中では、1レコード分のデータが item として展開されます。そのため、item.$id をレコード更新のレコードIDとして利用できます。
参照した情報
連携コネクタの試用方法や、kintoneの開発環境もこちらに記載されています。
当記事は連携コネクタ みんなの"やってみた"共有キャンペーンの関連記事です