APIトークンで解決!kintoneレコード登録時に作成者を任意設定する実装手法

kintoneアプリのカスタマイズ開発において、レコード登録APIを実行した際、作成者フィールドは自動的に「処理の実行ユーザー」になるため、ここを変えたいと頭を抱えた経験はないでしょうか。

「次のタスク担当者を作成者として登録したい」
「ポータルの『未処理』一覧に、正しい担当者を表示させて通知したい」

実は、この問題は「アプリ管理」権限を付与したAPIトークンを使用することで解決できます。

パスワード認証を使わずとも、APIトークンの設定とkintone.proxyを用いたレコード登録(レコード一括登録)を行うだけで、作成者フィールドは任意のユーザで設定可能です。これにより、プロセス管理設定のあるアプリの作成者を特定の担当者に割り当ててレコードを一括登録するようなこともでき、確実な通知フローを構築できるようになります。

本記事では、kintoneアプリのカスタマイズ開発を行うコアノーツ株式会社が、作成者を任意設定するための具体的な実装コードと設定手順を解説します。また、ドキュメントを詳しく読み込まないと意外と見落としがちな「APIトークン利用時の仕様」や、「ルックアップフィールド連携時の権限エラー」など、実務視点で詳しく触れていきます。

この記事を読み終える頃には、顧客からの要望を解決できる手段を一つ手に入れているはずです。

APIトークンに「アプリ管理」権限を付与すれば作成者を変更できる

結論からですが、レコード登録時に作成者に任意のユーザーを指定するには、アプリ管理権限が必要です。そのため、APIを実行する人に対してアプリ管理権限を付与するのが一番簡単な方法ではあるのですが、これだと意図しないアプリへの変更を加えられてしまうため現実的ではなく、推奨されません。そこで別の方法としては、APIトークンを利用したレコード登録を行い、そのAPIトークンに「アプリ管理」権限を付与するでという形で実現できます。

通常、レコード登録(またはレコード一括登録)用のkintone REST APIを画面上から実行する場合、レコードの作成者は「その操作を行ったログインユーザー」になります。しかし、APIトークン認証を使用し、かつそのAPIトークンにアプリ管理権限を持たせれば、作成者フィールドに任意のユーザーを指定したうえでレコードの登録が行えるようになります。

具体的な手順は次の通りです。

必須設定:APIトークン生成と「アプリ管理」権限の付与

まず、登録先となるkintoneアプリの設定画面を開き、「APIトークン」の設定へ進みます。 ここで「生成する」ボタンを押し、新しいトークンを作成します。

通常は「レコード閲覧」や「レコード追加」にチェックを入れますが、作成者を変更したい場合は、これらに加えて「アプリ管理」にもチェックを入れてください。
※アプリ管理権限は強い権限であるため、メモ欄にはなぜその権限を付けているのか、どのアプリで利用されるものなのか、といった情報を残しておくのを忘れずに。

設定したら保存し、必ず「アプリの更新」まで行います。これで準備は完了です。

なぜ「アプリ管理」権限が必要なのか

作成者や作成日時の変更といった操作はデータの整合性に関わる強力なものとみなされるため、単なるレコード追加権限だけでなく、アプリ自体を管理できるレベルの権限が求められているものと想定されます。

「レコードを1件登録する」などのAPIドキュメントの仕様にもちゃんと記載がありますが、作成者を変えて登録するケースはあまりないのではないかと思われるため、見落としやすいポイントです。
(記事執筆者は恥ずかしながら見落としていました・・・)

実装コード:kintone.proxyを使ってレコードの登録を行う

次に、JavaScriptカスタマイズでレコード登録を行うコードを記述します。 ここでは、APIトークンを使用したリクエストを行うために、kintone.proxy()メソッドを使用します。

以下は、新規レコードを登録し、同時に作成者を特定のユーザーコード(例: user_code_a)に設定するサンプルコードです。

注意

サンプルのためAPIトークンを直書きする例としていますが、実際は秘匿するなどの処理を行います。

例:kintoneプラグインにAPIトークンを秘匿して、JSカスタマイズから利用する
https://qiita.com/the_red/items/fe166efaf98ce165c411

function test() {
  // 登録先アプリのAPIトークン
  const API_TOKEN = '発行したAPIトークン';
  // 登録先アプリのID(適宜変更してください)
  const APP_ID = 100; 
  // kintoneのドメイン(適宜変更してください)
  // ※ゲストスペースの場合はゲストスペースIDを含めたパスにする必要があります
  const API_URL = 'https://(サブドメイン).cybozu.com/k/v1/record.json';

  const body = {
    'app': APP_ID,
    'record': {
      '文字列_1行': {
        'value': 'テスト登録データ'
      },
      // ここで作成者を指定します
      '作成者': {
        'value': {
          'code': 'user_code_a' // 設定したいユーザーのログイン名(コード)
        }
      }
    }
  };

  const header = {
    'X-Cybozu-API-Token': API_TOKEN,
    'Content-Type': 'application/json'
  };

  return kintone.proxy(API_URL, 'POST', header, body).then(function(args) {
    // args[0]: response body, args[1]: status code, args[2]: response header
    const resp = JSON.parse(args[0]);
    const status = args[1];
    
    if (status === 200) {
      console.log('登録成功!レコードID: ' + resp.id);
      return resp;
    } else {
      console.error('エラーが発生しました', resp);
      // 必要に応じてエラー処理を記述
    }
  }, function(error) {
    console.error('通信エラー', error);
  });
}

await test();

これで、実行したユーザー(ボタンを押した人)に関わらず、指定したユーザーが「作成者」として登録されます。

【重要】APIトークンを利用したレコード登録時の2つの注意点

基本的な実装は以上で完了ですが、実務で運用するアプリにおいては、注意すべき点が2つあります。これらを知らずに進めると、リリース直前に予期せぬエラーで躓いたり、セキュリティリスクを抱えたりすることになります。

登録先にルックアップフィールドがある場合は「参照先アプリのトークン」も必須

もし、レコード登録先のアプリに「ルックアップフィールド」が存在し、そのフィールド(またはコピー元のフィールド)に値をセットして登録しようとしている場合、先ほどのサンプルのままではエラーになる可能性が高いです。

よくあるのが、「GAIA_LO04」というエラーの発生です。

APIトークンを利用したレコード登録でルックアップフィールドがある場合のエラー

コード:GAIA_LO04
エラーメッセージ:フィールド「XXXX」の値「YYYY」が、ルックアップの参照先のフィールドにないか、またはアプリやフィールドの閲覧権限がありません。

APIトークンは、原則として「そのトークンを発行したアプリ」に対してのみ権限を持ちます。 しかし、ルックアップフィールドに値を登録するということは、kintone内部で「参照先アプリ(マスターアプリ)のデータを見に行く」という処理が発生しています。 登録先アプリのAPIトークンだけでは、この「参照先アプリを見に行く権限」が不足しているため、エラーが発生しています。

これを回避するには、参照先アプリ側でもAPIトークンを発行し(閲覧権限のみでOK)、それをリクエストヘッダーに含める必要があります。具体的には、X-Cybozu-API-Tokenヘッダーに複数のトークンをカンマ区切りで指定すればOKです。

ルックアップ先が複数ある場合は、必要な分だけAPIトークンをカンマで繋いで指定してください。これで、権限エラーを回避してスムーズに登録できるようになります。

「アプリ管理」権限は強力なためAPIトークンの取り扱いに厳重注意する

もう一点、セキュリティに関して注意すべき点があります。

作成者を任意設定するためにAPIトークンへ「アプリ管理」権限を付与しましたが、この権限は単にレコードを操作するだけでなく、アプリの設定変更や削除まで可能にする強力な権限です。 万が一、このトークンが外部に流出し悪用された場合、アプリの構造そのものが破壊されるリスクがあります。

JavaScriptファイル内にAPIトークンを直接記述(ハードコーディング)する方法は、ブラウザの開発者ツール等でトークンが見えてしまうリスクがあります。 社内限定のポータルなど閉じた環境であれば許容されるケースもありますが、よりセキュアな運用を目指す場合は、以下のような対策を検討するとよいでしょう。

  1. IPアドレス制限: kintone全体のアクセス制限を適切に設定し、許可されたネットワーク以外からのAPI実行を拒否する。
  2. プラグイン設定画面での隠蔽: APIトークンを設定画面側で保存し、フロントエンドのコード上には露出させない仕組みを利用する(または自作する)。

【応用】プロセス管理の「未処理」に正しい担当者を通知させる

ここまで、技術的な実装方法と注意点を解説してきました。 最後に、この作成者の任意設定が活用できる、具体的な応用シーンについて触れておきます。

最大のメリットは、kintoneのプロセス管理機能を、API連携したレコードでも正常に稼働させられる点にあります。

作成者を指定することでポータルの通知漏れを防ぐ

kintoneのプロセス管理において、最初のステータスの担当者を「作成者」に設定しているケースは多いと思っています。その一番の理由は、ポータル画面トップの「未処理」欄に表示されるようになるためですね。

今回紹介した手法を用いて、レコード登録時に「本来の担当者」が作成者となるように設定しておけば、レコードが作られた瞬間にそのユーザーの「未処理」に表示されるようになります。 「APIでデータは作ったけれど、担当者が気づいていない」というよくある課題を解消することができるようになります。

実例:申請承認後に報告書アプリへ自動登録するフロー

あるお客様では、チームで出張に行く際に、代表者の一人が「出張申請アプリ」で申請を行います(アプリ内には同行者フィールド(ユーザー選択フィールド)があり、そこにチームメンバー全員を設定)。 出張申請の承認が完了した後、「出張報告書アプリ」へ同行者の数だけ、レコードを一括で自動登録する処理を実装しました。

単に出張報告書アプリにレコードを一括登録するだけでなく、作成者が「申請者本人(や各同行者)」となるように設定することで、承認が降りた瞬間に「次は報告書を提出する必要がある」という状態を実現しています。

具体的な実装の背景や、全体の業務フローについては、以下の記事で詳しく解説しています。ぜひ併せてご覧ください。

参考:申請承認後に報告書アプリへレコードを一括で自動登録する事例

まとめ

本記事では、kintoneのレコード登録APIにおいて、作成者を任意のユーザーに設定する実装手法を解説しました。

ポイントを整理します。

  • 作成者の変更: APIトークンに「アプリ管理」権限を付与することで、作成者フィールドの指定が可能になる。
  • 実装方法: kintone.proxyを使用し、ヘッダーにAPIトークンを含めてレコード登録APIを使用する。
  • ルックアップの注意点: 登録先にルックアップがある場合、参照先アプリのAPIトークンもヘッダーに含めないとエラー(GAIA_LO04)になる。
  • セキュリティ: 「アプリ管理」権限は強力なため、トークンの管理・隠蔽には十分配慮する。

「作成者が変えられない」という標準仕様の壁も、APIトークンの仕様を正しく理解すれば乗り越えられます。 お客様から「担当者に通知を飛ばしたい」「未処理一覧に出したい」という要望があった際は、ぜひこの手法を検討してみてください。

関連記事