kintone 2026年8月アップデート ルックアップのchangeイベント正式化・組織別の利用状況・ポータル10枚

本記事は、kintoneの構築・カスタマイズやプラグイン開発の実務経験を持つ筆者が、サイボウズ公式のアップデート情報とAPIアップデート情報をもとに、2026年8月のkintone（キントーン）アップデートを現場目線で整理したものです。

2026年8月9日に実施されるアップデートは、JavaScriptカスタマイズを書く人にとって節目の回です。長年「できない」とされてきたルックアップフィールドの変更検知が、ようやく標準機能として使えるようになります。

この記事を読むと、次のことが分かります。

• ルックアップのchangeイベントが正式リリースされ、これまでの回避策がどう変わるのか
• 新しく取れるconfirmed・recordIdで何が実現できるのか（クリア連動処理を含む）
• 管理者向けの変更：組織ごとの利用状況、ポータルの枚数拡大
• 既存のカスタマイズやプラグインに、緊急の改修が必要かどうか

まずは全体像です。

カテゴリ	主な変更点	対象
JavaScript API	ルックアップでchangeイベントが発生。confirmed・recordIdを追加	開発者（全テナント自動適用）
利用状況	利用状況ダッシュボードで組織ごとに確認可能	システム管理者
ポータル	ポータルのページ追加が3枚→10枚	ワイドコース限定
複数ドメイン管理	ユーザーごとの利用ドメイン一覧画面を追加	ワイドコース限定
AI	スレッド要約AIがAndroidアプリで利用可能	全ユーザー
開発基盤	モバイルの検索・未処理・設定画面の基盤刷新	モバイル利用者

本命：ルックアップでchangeイベントが発生するようになる

今回いちばん実務に効くのがこれです。しかもアップデートオプションでの有効化は不要で、8月9日のメンテナンス後は全テナントに自動で適用されます。

これまでは「発火しない」が常識だった

kintoneのルックアップは、これまでカスタマイズの鬼門でした。ルックアップフィールドのフィールドコードを指定してchangeイベントを登録しても、標準環境では発火しなかったのです。

そのため実装者は、ルックアップが値をコピーする先のフィールドを発火点にするという回避策を取ってきました。

// これまで：ルックアップ自身を指定しても発火しない
kintone.events.on('app.record.edit.change.ルックアップ', handler);

// これまでの定石：コピー先フィールドを発火点にする
kintone.events.on('app.record.edit.change.コピー先フィールド', handler);

この方式には明確な弱点がありました。【クリア】ボタンを押したときは、コピー先のchangeも発火しないのです。そのため「ルックアップがクリアされたら、それを前提に入力していた項目も空に戻す」といった連動処理は、どう工夫しても組めませんでした。

8月9日から何が変わるのか

ルックアップフィールドのフィールドコードを指定したchangeイベントが、そのまま発火するようになります。対象は次の4つです。

画面	イベント
レコード追加（PC）	app.record.create.change.フィールドコード
レコード編集（PC）	app.record.edit.change.フィールドコード
レコード追加（モバイル）	mobile.app.record.create.change.フィールドコード
レコード編集（モバイル）	mobile.app.record.edit.change.フィールドコード

発火するタイミングは3つです。

1. 【取得】で参照先レコードを確定したとき（一致が1件で自動取得された場合と、複数候補からダイアログで選んだ場合の両方を含みます）
2. ルックアップフィールドをクリアしたとき
3. ルックアップフィールドからフォーカスが外れたとき

ただし無条件ではありません。検索用のキーワードを変更した場合か、選択した参照先レコードが変更されている場合だけ発火します。何も触らずにフォーカスを外しただけでは発火しない、という理解が正確です。

もう一つ、処理順の仕様も明記されています。ルックアップ自身のchangeは、コピー先フィールドのchangeより先に発火します。両方にハンドラを登録している場合の順序が保証されるため、設計が読みやすくなります。

confirmedとrecordIdで「状態」が分かるようになる

イベントオブジェクトやJavaScript APIで取得できるレコード情報に、2つのプロパティが追加されます。

プロパティ	型	内容
confirmed	真偽値	参照先レコードが確定しているか。確定時と【クリア】した時にtrue
recordId	文字列	参照先レコードのレコードID。未入力・未確定のときはnull

この3つの値の組み合わせで、ルックアップの状態を正確に判別できます。

状態	value	confirmed	recordId
入力して取得済み	"kintone"	true	"（レコードID）"
入力したが未取得	"kintone"	false	null
未入力（初期状態、またはクリア後）	""	true	null

取得済みのときの値は、次のような形で入ってきます。

"フィールドコード": {
  "type": "SINGLE_LINE_TEXT",
  "value": "kintone",
  "confirmed": true,
  "recordId": "10"
}

typeがLOOKUPではなく参照先フィールドの型（この例ではSINGLE_LINE_TEXT）で返ってくる点は従来どおりです。ルックアップかどうかの判定は、フィールド情報のlookupプロパティの有無で行います。

これで「クリア連動処理」が組めるようになる

実務でいちばん大きいのはここです。上の表を見ると、クリア後だけがconfirmed: true かつ value: "" かつ recordId: null という固有の組み合わせになっています。

つまり、こう書けばクリアを検知できます。

kintone.events.on('app.record.edit.change.顧客コード', (event) => {
  const lookup = event.record.顧客コード;
  const isCleared = lookup.confirmed === true
    && lookup.value === ''
    && lookup.recordId === null;

  if (isCleared) {
    // ルックアップをクリアしたので、手入力してもらっていた項目も空に戻す
    event.record.訪問メモ.value = '';
    event.record.確認済み.value = [];
  }
  return event;
});

ここで空にしているのは、ルックアップのコピー先ではなく、担当者が手で入力した項目です。コピー先フィールドはルックアップが値の出どころを持っているため、JavaScriptから書き換える対象には向きません。クリア連動で面倒を見たいのは、たいてい「その取引先を選んだ前提で人が書き足した情報」や「独自のJavaScript・プラグインが埋めた項目」のほうです。

これまでは、この分岐に入るためのきっかけ自体が取れませんでした。クリアを検知する方法がなかったため、「マスタの選択をやり直したのに、前提が変わった手入力の情報だけ古いまま残る」という状態を、コードで防ぐことができなかったのです。8月9日以降は、そこに手を打てるようになります。

参照先のレコードIDがrecordIdで直接取れるのも見逃せません。これまでレコードIDを知るにはREST APIで参照先を検索し直す必要がありました。追加のAPIコールなしでIDが手に入るので、参照先レコードへのリンクを組み立てる、といった処理が軽くなります。

既存のカスタマイズやプラグインへの影響

結論として、緊急の改修は不要です。

これまでの定石だったコピー先フィールドを発火点にする方式は、8月9日以降も引き続き動作します。今回の変更は「発火しなかったものが発火するようになる」追加であって、既存の発火点が失われるわけではありません。

ただし、次の2点は確認しておく価値があります。

• ルックアップフィールドのコードでchangeを登録したまま動かないので放置していたコードがあると、8月9日から突然動き出す可能性があります
• コピー先のchangeとルックアップ自身のchangeの両方にハンドラがあると、ルックアップ側が先に走るため、処理が二重になっていないか確認しておきましょう

新規に書くなら、これからはルックアップ自身のchangeを使うほうが素直です。専用の照合キーフィールドを用意する必要がなくなり、クリアにも対応できます。

ルックアップそのものの仕組みや設定方法を確認したい方は、kintoneのルックアップの使い方と設定方法にまとめています。

組織ごとの利用状況が見られるようになる

管理者向けの変更です。利用状況ダッシュボードで、利用状況を表示する組織を選べるようになります。選択できる組織は、cybozu.com共通管理で設定されているものです。

各組織の利用ユーザー数やアプリへの操作回数の推移を追えるため、次のような使い方ができます。

• 利用が定着していない組織を特定する（全体平均では見えなかった偏りが分かる）
• 研修や社内展開などの施策を打ったあと、その組織の数値が動いたかを確認する

kintoneが「一部の部署でしか使われていない」という状態は珍しくありません。これまで組織を指定して絞ることができなかったところに組織の軸が入るので、どこに手を入れるべきかの判断材料になります。定着が課題だと感じている方は、kintoneが定着しない理由もあわせてご覧ください。

ポータルのページが10枚まで（ワイドコース限定）

ポータルに追加できるページが、従来の3枚から10枚に増えます。1枚目のポータルとは別に、2枚目以降を10枚まで追加できる形です。

部門別・プロジェクト別にポータルを作り分けやすくなります。なおワイドコース限定の変更で、それ以外のコースでは機能・制限に変更はありません。

その他の変更点

残りは簡潔にまとめます。

• スレッド要約AIがAndroid版モバイルアプリで利用可能に。移動中にスレッドの議論を追いつけるようになります。利用にはモバイルアプリ自体のアップデートが必要で、iOS版も今後予定されています。機能自体の詳細は2026年6月のアップデート解説で扱っています
• 複数ドメイン管理で［ユーザー情報］画面が追加（ワイドコース限定）。ユーザーごとに、登録されているドメインと使用状態（使用中／停止中）の一覧を確認できます。人事異動でドメインの利用者を入れ替えたあとの確認に向いています
• モバイルの「検索画面」「未処理画面」「設定画面」のフロントエンド基盤を刷新。操作方法や見た目に大きな変更はないとされていますが、モバイルでカスタマイズを当てている場合はDOM構造が変わる可能性があるため、念のため動作確認をしておくと安心です
• 従来の通知画面への切替機能は8月版でも継続。7月版で「8月版で提供終了予定」と案内されていましたが、リリース予定が見直され継続となりました。終了時期は改めて案内される予定です

まとめ：今月押さえる3点

• ルックアップのchangeイベントが正式リリース（8月9日・全テナント自動適用・オプション設定不要）。confirmedとrecordIdが追加され、クリア連動処理と参照先レコードIDの取得が標準でできるようになる
• 既存カスタマイズの緊急改修は不要。コピー先フィールド方式は引き続き動作する。ただし「動かないので放置していたルックアップ自身のchange」が動き出す点と、ハンドラの二重実行には注意
• 管理者は組織ごとの利用状況を確認できるようになる。定着していない組織の特定に使える。ポータル10枚化と複数ドメイン管理の追加はワイドコース限定

モバイル基盤の刷新は「見た目は変わらない」とされていますが、モバイルにカスタマイズを入れている環境では、8月9日以降にひととおり触って確認しておくことをおすすめします。

kintoneの「あとちょっと」はプラグインで

ルックアップまわりは、標準機能だけでは手が届かない場面がまだ残ります。マスタ側を直したときに取得済みの値を追従させたい、入力のたびに【取得】を押すのが面倒——こうした課題は、コードを書かずにプラグインで解決できます。

• ルックアップサジェスト for kintone — 入力中にライブサジェストを表示し、画面遷移なしで取得まで完結（無料）
• ルックアップ自動同期 for kintone — マスタ側の変更を、取得済みのコピー値に追従させる（プレミアム）

カスタマイズやプラグイン選定のご相談は、お問い合わせからお気軽にご連絡ください。

関連記事・サービス

• kintoneのルックアップの使い方と設定方法 — 設定手順・絞り込み・テーブル内ルックアップ
• ルックアップとは（用語集） — 用語の意味と関連レコード一覧との違い
• kintone 2026年6月アップデート — kintone AIの正式提供とOR検索
• kintoneが定着しない理由 — 利用状況の読み解きと打ち手
• kintoneプラグイン一覧 — 無料で使えるプラグインをまとめて掲載