kintone 多言語対応の進め方｜表示言語・アプリ設計・翻訳連携を解説

はじめに

海外拠点、外国籍メンバー、海外取引先と同じ業務アプリを使う場合、kintoneを多言語で運用したいという相談が出てきます。日本語の画面を英語で表示したい、入力された問い合わせ内容を翻訳したい、海外拠点でも同じワークフローを使いたい、といったニーズです。

ただし、kintoneの多言語対応は「画面の言語を切り替えるだけ」で完結しません。標準機能で変えられる表示言語、アプリごとに設計する項目名、ユーザーが入力するレコード本文、通知文、添付資料の言語は別々に考える必要があります。

特に海外拠点と同じアプリを使う場合、翻訳の有無だけでなく、誰がどの言語で入力し、どの言語で承認し、どのデータを本社が集計するのかを先に決める必要があります。ここを決めずに項目だけ翻訳すると、現場では入力しやすくなっても、集計や確認の段階で意味がそろわない状態になります。

対象読者は、kintoneをすでに使っていて海外拠点へ広げたい管理部門、英語対応が必要な営業・サポート部門、これからkintoneで業務アプリを作る情報システム担当者です。標準設定で済むのか、追加開発や外部API連携が必要なのかを判断できるように整理します。

この記事では、kintone 多言語対応で最初に分けるべき範囲、標準設定でできること、アプリ設計で補うこと、外部翻訳APIを使う構成、導入時の注意点を実務目線で整理します。

kintone 多言語対応で最初に分けるべき範囲

kintoneで多言語対応を考えるときは、まず次の4つを分けます。

範囲	内容	主な対応方法
kintone本体の表示	メニュー、共通管理、システムメッセージ	ユーザーごとの表示言語、システム言語
アプリの文言	アプリ名、フィールド名、説明文、選択肢	アプリ設計、命名ルール、必要に応じたカスタマイズ
レコードの内容	顧客名、問い合わせ本文、作業メモ、商品説明	入力ルール、翻訳欄、外部翻訳API
運用文書	マニュアル、通知文、承認コメント	テンプレート、定型文、社内ルール

この切り分けをしないまま「多言語化したい」と依頼すると、開発範囲が曖昧になります。画面表示だけでよいのか、入力された業務データも翻訳したいのか、海外拠点ごとに入力ルールを変えたいのかで、設計も費用も変わります。

kintone 多言語対応の最初の判断は、標準設定で足りる表示の話なのか、業務データを翻訳・管理する仕組みの話なのかを分けることです。

標準の表示言語設定でできること

kintoneは、ユーザーが個別に表示言語を設定できます。サイボウズ公式ヘルプでは、表示言語として日本語、英語、中国語（簡体字）、中国語（繁体字）、スペイン語、ポルトガル語（ブラジル）、タイ語、マレー語が案内されています（kintoneヘルプ: システムの言語の設定）。

また、kintone共通管理から送信される一部メールや、APIのエラーメッセージに使うシステム言語も設定できます。ただし、公式ヘルプでも説明されている通り、英語以外の表示言語を設定していても、一部の画面やメールでは英語で表示される場合があります。

つまり標準の表示言語設定は、kintone本体のUIを使いやすくする機能です。ユーザーが入力したレコード内容を自動翻訳したり、アプリごとの業務文言をすべて自然な多言語に変換したりする機能とは分けて考える必要があります。

やりたいこと	標準設定での考え方
ユーザーごとに画面言語を変える	表示言語設定で対応
共通管理メールやAPIエラーの言語を整える	システム言語設定を確認
顧客からの問い合わせ本文を翻訳する	標準表示言語ではなく、翻訳運用やAPI連携で設計
アプリ独自の用語を自然な英語にする	フィールド名、説明文、選択肢を業務用語として整備

アプリを多言語で使うための設計

海外拠点でも同じkintoneアプリを使うなら、項目名を翻訳するだけでなく、入力ルールを統一することが重要です。たとえば、日付形式、通貨、住所、電話番号、氏名の表記、商品コード、拠点コードが国ごとに揺れると、集計や検索が難しくなります。

アプリ設計では、表示名とシステム上のフィールドコードを分けて考えます。kintone JavaScript APIやREST APIでレコードを操作する際は、フィールド形式に合わせて値を取得・設定します。cybozu developer networkでは、フィールドを指定する方法として、フィールド名またはフィールドコードを使うことが説明されています（フィールド形式）。

多言語運用では、フィールドコードは英数字で安定させ、画面上の表示名や説明文を利用者に合わせる設計が扱いやすくなります。

設計項目	推奨方針
フィールドコード	英数字で固定し、API連携や集計で使いやすくする
フィールド名	日本語/英語の併記や利用者向け表現にする
選択肢	拠点ごとに意味が変わらない値へ統一する
入力ルール	通貨、日付、住所、電話番号、単位を明確にする
通知文	承認依頼、差し戻し、期限通知の言語を確認する
マニュアル	画面キャプチャと用語集を言語別に用意する

多言語対応で重要なのは、翻訳の前に、業務用語と入力ルールをそろえることです。ここが曖昧なままだと、英語表示にしてもレコード内容の意味が伝わりません。

外部翻訳APIやREST APIを使う構成

問い合わせ本文、作業メモ、商品説明など、ユーザーが入力するレコード内容まで翻訳したい場合は、外部翻訳サービスやAPI連携を検討します。

kintone REST APIは、アプリレコードの作成、取得、更新、削除などに対応し、HTTPS、JSON、UTF-8を使います（Kintone REST API Overview）。APIのレスポンス言語を指定したい場合は、Accept-Languageヘッダーも確認対象になります。

実装構成は、主に次の3パターンです。

構成	内容	向いているケース
手動翻訳欄	日本語欄、英語欄などを分けて入力	重要文書、翻訳品質を人が確認する業務
外部翻訳API連携	レコード保存時に翻訳APIへ送信し、翻訳結果を別フィールドへ保存	問い合わせ一次対応、社内共有メモ
中間サーバー連携	kintoneと翻訳サービスの間にサーバーを置く	APIキー保護、ログ管理、複雑な権限制御が必要な業務

API Token認証を使う場合は、トークンの権限、対象アプリ、保管方法を慎重に設計します。kintone Developer Programでは、API Tokenはアプリごとに生成され、API Tokenで実行できる操作には制約があることが説明されています（Authentication）。

外部翻訳APIを使う場合、機密情報や個人情報を外部サービスへ送ってよいかも確認が必要です。社内規程、契約条件、保存期間、ログの扱いを確認せずに自動翻訳を入れると、セキュリティやコンプライアンス上の問題になる可能性があります。

導入メリットと注意点

kintoneを多言語で使えるようにすると、海外拠点との情報共有、外国籍メンバーのオンボーディング、海外顧客対応のスピード改善に役立ちます。日本本社が作った業務アプリを海外拠点でも使いやすくなれば、Excelやメールで分散していた情報を集約しやすくなります。

一方で、多言語対応は「翻訳すれば終わり」ではありません。業務用語、承認ルール、権限、通知、マニュアル、サポート体制まで整えないと、現場で使われないアプリになります。

メリット	注意点
海外拠点と同じアプリを使える	拠点ごとの業務ルール差を吸収する設計が必要
外国籍メンバーが操作しやすくなる	UI表示と業務用語の翻訳は別管理
問い合わせや案件情報を共有しやすい	レコード本文の翻訳品質を確認する仕組みが必要
グローバルな集計がしやすい	通貨、単位、日付、住所形式の統一が必要

kintone 多言語対応は、海外拠点向けの画面翻訳ではなく、グローバルで同じ業務データを扱うための運用設計です。

外注前に確認するチェックリスト

外注前には、次の項目を整理しておくと見積もりと実装範囲が明確になります。

項目	確認内容
対象言語	英語、中国語など、どの言語を優先するか
対象範囲	UI表示、アプリ文言、レコード本文、通知文、マニュアルのどこまでか
翻訳方法	人手翻訳、自動翻訳、外部翻訳API、併用のどれか
データ設計	言語別フィールド、翻訳ステータス、原文保存の有無
権限	拠点、部署、言語ごとに閲覧・編集権限を分けるか
API連携	翻訳API、基幹システム、CRMなどとつなぐか
運用	翻訳レビュー担当、用語集、更新手順を誰が持つか

関連するkintoneの活用パターンを確認したい場合は、kintone 業務アプリの活用事例も参考になります。導入費用や運用コストを把握したい場合は、kintone 料金はいくら？プラン別の費用と数年運用の総コスト比較を確認してください。補助金活用を検討する場合は、kintone IT導入補助金の活用方法も合わせて整理すると進めやすくなります。

まとめ

kintoneの多言語対応では、標準の表示言語設定でできることと、アプリ設計・レコード翻訳・外部API連携で補うことを分けて考える必要があります。画面を英語にするだけなら比較的シンプルですが、海外拠点と同じ業務データを扱うなら、フィールド設計、入力ルール、通知、権限、翻訳レビューまで含めた設計が必要です。

導入前には、全社共通で使う項目と拠点ごとに変えてよい項目を分けてください。全社で見るKPI、顧客ランク、案件ステータス、承認状態は共通化し、現地の補足メモや顧客対応履歴は言語別に残せるようにすると、現場の使いやすさと本社側の管理しやすさを両立しやすくなります。

まずは対象言語、対象範囲、翻訳方法、運用担当を決め、標準機能で足りる範囲と追加開発が必要な範囲を切り分けましょう。kintoneを海外拠点や多国籍チームで使う場合は、小さなアプリから試し、現場のフィードバックを受けながら多言語対応範囲を広げる進め方が現実的です。

最初から全画面を完全翻訳するより、利用頻度の高いアプリと重要な業務フローから段階的に多言語化するほうが、失敗しにくい進め方です。

https://nocoderi.co.jp/2025/04/04/kintone-business-app-case-studies/

https://nocoderi.co.jp/2026/06/12/kintone-pricing/

https://nocoderi.co.jp/2025/04/04/kintone-it-subsidy-guide/