kintone業務設計研究所 > kintone経費精算の設計方法|申請・承認・集計・会計連携の境界

kintone経費精算の設計方法|申請・承認・集計・会計連携の境界

2026年6月9日

24分で読めます

kintoneで経費精算を作る前に決めるべき、申請ヘッダー、経費明細、証憑、社内規定、承認、差し戻し、支払、集計、freee・会計連携、専用経費精算SaaSとの境界を整理します。

kintone
経費精算
業務設計
アプリ設計
会計連携
承認フロー
助手
助手

kintoneで経費精算を作りたいです。申請者、日付、金額、用途、領収書を入れて、上長承認に回せばよいでしょうか。

博士
博士

小さな申請なら始められる。ただ、経費精算は申請フォームだけでは足りない。明細、証憑、社内規定、承認、支払、会計連携を混ぜると、経理確認にも税務確認にも使いづらくなる。

kintoneで経費精算を作るとき、最初に考えやすいのは申請フォームです。

申請者、申請日、経費日、金額、用途、勘定科目、領収書、承認者、ステータス。

これをアプリに入れて、プロセス管理で承認に回せば、経費精算らしい画面は作れます。

ただし、実務で困るのは、経費申請を入力できないことではありません。

本当に崩れやすいのは、次のような状態です。

  • 1つの申請に複数明細があるのに、申請と明細を同じ項目で扱っている
  • 領収書や請求書の保存ルールが決まっていない
  • 社内規定の上限、日当、交通費、交際費の扱いが手入力になっている
  • 承認済みだが、経理確認や支払対象に回っていない
  • 差し戻し理由や修正履歴が残らない
  • 支払済みか、給与精算済みか、会計ソフトに登録済みか分からない
  • インボイスや電子帳簿保存の確認をkintoneだけで済ませようとしている
  • freeeなどの会計ソフトと、どちらを正本にするか決まっていない
  • 経費精算SaaSを使うべき範囲まで、kintoneで作り込もうとしている

kintoneで経費精算を作るなら、最初に設計すべきなのは「経費精算アプリ」ではありません。

申請ヘッダー、経費明細、証憑、社内規定、承認、支払、会計連携、専用SaaSとの分担をどこで分けるかです。

kintone経費精算で最初に決めるべきなのは、承認ステータスではなく、「申請・証憑・支払・会計のうち、どれをkintoneの正本にするか」です。

この記事では、kintoneで経費精算を崩れにくい業務システムとして設計する方法を整理します。

kintone予実管理の設計方法はこちら
kintone勤怠管理の設計方法はこちら

経費申請、明細、証憑、承認、精算集計、支払、freee・会計連携、専用経費精算SaaSを分けるkintone経費精算の構成図

先に結論:経費精算は「申請」「明細」「証憑」「会計」を分ける

kintoneで経費精算を作るとき、経費精算アプリ1つだけでも始めることはできます。

ただし、経理確認や会計連携まで見据えるなら、最初から次の情報を分けて考えます。

分けるもの 1レコードの意味 役割
社員・部門 1人、1所属、1承認ルート 申請者、所属、承認者、支払先を持つ
経費申請 1回の精算申請 申請者、対象期間、合計、状態を持つ
経費明細 1つの経費行 日付、用途、金額、科目、税区分を持つ
証憑 1つの領収書、請求書、画像 明細の根拠として保存・確認する
社内規定チェック 1つの判定 上限、日当、交通費、承認要否を判断する
承認 1回の上長・経理確認 承認、差し戻し、修正依頼を残す
精算集計 1回の締め・支払対象 承認済み経費を支払単位でまとめる
支払依頼 1回の振込、給与精算 支払済み、未払い、支払日を管理する
会計連携 1回の仕訳候補・取込 freee等への登録結果やエラーを追う

このうち、すべてをkintoneの正本にする必要はありません。

むしろ、証憑保存、インボイス確認、仕訳、未払金、振込、給与連携まで含むなら、専用の経費精算SaaSや会計ソフトを使った方がよいケースが多いです。

kintoneは、社内の申請、承認、差し戻し、経費集計、会計連携前の確認に向いています。

会計ソフトは、仕訳、税区分、未払金、支払、帳簿に向いています。

専用経費精算SaaSは、電子帳簿保存、OCR、ICカード連携、インボイス確認、規定チェック、会計連携まで一体で扱いやすいです。

領域 kintoneで持ちやすい 専用SaaS・会計ソフトを正本にしやすい
経費申請 申請者、部門、対象期間、承認状態 必要に応じて参照
経費明細 用途、金額、プロジェクト、部門 税区分、仕訳、会計上の科目
証憑 添付、確認状態、差し戻し理由 電子帳簿保存対応、OCR、検索要件
承認 上長確認、経理確認、差し戻し 専用SaaSの規定チェックと併用
支払 支払対象の集計、支払依頼状態 振込、給与連携、未払管理
会計 連携ログ、エラー、再実行 仕訳、税区分、帳簿、決算

経費精算で重要なのは、申請を通すことだけではありません。

その経費が、社内規定に合っているか。

証憑が確認できるか。

承認されたか。

支払対象になったか。

会計ソフトに正しく渡ったか。

ここまで追えることです。

kintone経費精算が向く業務と向かない業務

kintoneは、経費精算に使えます。

特に、少人数の立替経費、部門内の簡易申請、プロジェクト別の経費確認、会計連携前の社内確認には向いています。

kintoneに向く経費精算 理由
小規模な立替経費申請 申請、承認、差し戻しをシンプルに作れる
部門別・案件別の経費確認 部門、案件、管理科目とつなげやすい
経理確認前の申請受付 不備、証憑、承認状態を一覧化できる
出張申請と精算の軽い管理 申請、日当、交通費、承認をまとめやすい
既存会計ソフトの前段管理 freee等へ渡す前の確認や補足情報を持てる
社内規定が比較的単純な経費 上限、承認者、科目程度なら設計しやすい

一方で、次の条件が強い場合は、kintoneだけで完結させない方がよいです。

kintoneだけでは重い経費精算 理由
電子帳簿保存の要件対応を含めたい 証憑保存、検索、訂正削除履歴などの確認が必要
インボイス確認を厳密に行いたい 登録番号、税率、記載事項、仕入税額控除の確認が絡む
ICカード・クレカ連携が必要 明細取込、重複チェック、突合が専用化しやすい
複雑な交通費・日当規定がある 経路、距離、役職、地域、宿泊などの条件が多い
給与連携・振込データ作成まで必要 支払処理、銀行連携、給与計算との境界が必要
大量の領収書OCRを使いたい OCR精度、補正、証憑管理UIが重要になる

kintoolsの経費精算ページでも、kintoneのサンプルアプリだけでは社内規定に基づく処理が不足し、複数アプリやJavaScript、プラグインで補う必要があるという考え方が示されています。

kintools:kintone 出張経費精算

この指摘は実務上かなり重要です。

経費精算は、申請フォームを作れば終わる業務ではありません。

社内規定、証憑、承認、支払、会計がつながるため、kintone標準機能で作る範囲と、カスタマイズや専用SaaSへ逃がす範囲を分ける必要があります。

kintone経費精算は、経費精算SaaSを再発明するためではなく、自社の申請・承認・会計連携前の確認を整理するために使うと強いです。

申請・明細・証憑・承認を分ける

経費精算で最初に分けるべきなのは、申請ヘッダーと明細です。

1回の経費精算に、交通費、宿泊費、備品購入、会議費など複数の明細が入ることがあります。

それぞれ、日付、科目、税区分、証憑、承認要否が違います。

アプリ 1レコードの単位 主な項目
社員・部門アプリ 1人、1所属 所属、上長、承認者、支払先
経費申請アプリ 1回の申請 申請者、対象期間、合計、状態
経費明細アプリ 1つの経費行 日付、用途、金額、科目、税区分
証憑アプリ 1つの領収書・請求書 ファイル、発行元、登録番号、確認状態
承認履歴アプリ 1回の承認・差し戻し 承認者、日時、コメント、差し戻し理由
支払・精算アプリ 1回の支払対象 支払日、支払方法、支払状態
連携ログアプリ 1回の会計・支払連携 出力件数、エラー、再実行

経費申請アプリに持たせる項目

経費申請アプリは、申請全体を管理します。

フィールド 設計意図
申請番号 文字列、採番 申請全体のキーにする
申請者 ユーザー選択、社員マスタ 誰の経費か
所属部門 ルックアップ、組織選択 部門別集計や承認ルートに使う
対象期間 日付 月次や出張期間を示す
申請種別 ドロップダウン 通常経費、出張精算、仮払精算など
合計金額 集計、数値 明細合計を表示する
承認者 ユーザー選択 上長や経理担当を明確にする
申請状態 ステータス 下書き、申請中、承認済み、差し戻し、支払済み
支払方法 ドロップダウン 振込、給与精算、現金など
経理メモ 文字列複数行 補足、修正理由を残す

経費明細アプリに持たせる項目

経費明細は、経費の実体です。

フィールド 設計意図
関連申請 ルックアップ、関連レコード どの申請の明細か
経費日 日付 いつ発生した経費か
経費区分 ドロップダウン 交通費、宿泊費、会議費、備品など
用途・内容 文字列複数行 何のための経費か
金額 数値 精算金額
税込・税抜区分 ドロップダウン 会計連携時の確認に使う
税率 ドロップダウン 10%、8%、対象外など
管理科目 ルックアップ、ドロップダウン 予実や部門集計に使う
勘定科目候補 ドロップダウン 会計連携前の候補として持つ
案件・プロジェクト ルックアップ 案件別経費を見る場合に使う
証憑 関連レコード、添付 領収書や請求書とつなぐ
規定チェック結果 ドロップダウン OK、要確認、超過、対象外

明細を申請アプリ内のテーブルで持つ方法もあります。

少人数で、明細別の承認や会計連携が不要なら、テーブルから始めてもよいです。

ただし、明細ごとに証憑、税区分、科目、案件、承認要否、会計連携状態を持つなら、明細を別アプリにした方が扱いやすくなります。

証憑アプリに持たせる項目

証憑は、経費の根拠です。

フィールド 設計意図
関連明細 ルックアップ、関連レコード どの経費明細の証憑か
証憑種別 ドロップダウン 領収書、請求書、クレカ明細など
発行日 日付 証憑の日付
発行元 文字列 店舗名、取引先名
登録番号 文字列 インボイス確認が必要な場合に持つ
金額 数値 明細金額との照合
添付ファイル 添付ファイル 画像やPDF
確認状態 ステータス 未確認、確認済み、不備、差し戻し
不備理由 文字列複数行 金額不一致、証憑不足など

証憑は、単に画像を添付すればよいわけではありません。

電子帳簿保存法やインボイス制度の要件が関係する場合は、税理士や経理責任者と確認し、専用SaaSや会計ソフトで管理する範囲を決めます。

国税庁のインボイス制度ページでも、適格請求書等保存方式は仕入税額控除の方式として説明されています。

国税庁:適格請求書等保存方式(インボイス制度)

また、国税庁は電子帳簿保存法のスキャナ保存に関する一問一答も公開しています。

国税庁:電子帳簿保存法一問一答(スキャナ保存関係)

この記事では税務判断そのものは扱いません。

kintoneで経費精算を作る場合も、証憑保存や税務上の要件は、必ず経理責任者や税理士と確認してください。

社内規定と自動計算

経費精算では、社内規定が重要です。

規定が曖昧なままアプリを作ると、承認者や経理担当が毎回判断することになります。

規定 設計すること
交通費 経路、上限、定期区間、領収書要否
出張費 宿泊費上限、日当、地域、役職
交際費 参加者、目的、上限、承認者
会議費 人数、単価、目的、取引先
備品購入 事前承認、金額上限、資産区分
仮払 仮払額、精算期限、残額返金
クレカ利用 個人立替か法人カードか、重複精算防止

kintone標準の計算フィールドだけで足りる場合もあります。

たとえば、金額、税率、合計、日当、距離単価のような単純計算です。

一方で、複雑な条件分岐は標準機能だけでは重くなります。

処理 kintone標準で始めやすい カスタマイズや専用SaaSを検討
合計金額 数値・計算フィールド 明細別の複雑な按分
税込・税抜 計算フィールド 軽減税率、非課税、複数税区分の厳密処理
日当 役職・日数が単純 地域、時間帯、宿泊、海外出張
上限チェック 金額しきい値 部門、役職、案件、取引先ごとの条件
承認者判定 所属部門や金額で分岐 代理承認、複数段階、例外ルート
交通費 金額手入力 経路検索、ICカード連携、定期区間控除

kintoolsのページでも、社内規定に基づくルールを入れることで手入力を減らせるという考え方が紹介されています。

重要なのは、自動化できるかどうかではありません。

自動判定してよいものと、経理が確認すべきものを分けることです。

経費精算では、すべてを自動判定するより、「自動で通す経費」と「人が確認する経費」を分ける方が現実的です。

承認フローと差し戻し

経費精算では、承認フローを重くしすぎない方がよいです。

ただし、承認の責任範囲は明確にします。

上長は、業務上必要な経費かを確認する。

経理は、証憑、科目、税区分、支払対象として問題ないかを確認する。

この2つは同じ承認ではありません。

確認者 見ること
上長 業務上必要か、金額が妥当か、案件・部門が正しいか
経理 証憑、科目、税区分、支払条件、会計連携の可否
管理部門 社内規定、仮払、例外承認
税理士・会計担当 税務上の扱い、インボイス、証憑保存方針

kintoneのプロセス管理では、レコードにステータスを持たせ、作業者やアクションを設定できます。

kintoneヘルプ:プロセス管理

経費精算では、次のような状態で十分なことが多いです。

ステータス 意味 次に必要な行動
下書き 申請者が入力中 明細と証憑をそろえる
申請中 上長確認待ち 業務上必要か確認する
上長承認済み 経理確認待ち 証憑、科目、税区分を確認する
経理確認済み 支払対象 締め処理・支払へ回す
差し戻し 修正が必要 不備理由を確認して再申請する
支払済み 精算完了 会計連携・支払結果を残す
取消 申請しない 取消理由を残す

差し戻しでは、理由を必ず残します。

差し戻し理由
証憑不足 領収書がない、画像が不鮮明
金額不一致 明細金額と領収書金額が違う
用途不足 何のための経費か分からない
科目確認 勘定科目や管理科目の判断が必要
規定超過 上限を超えている
承認者違い 所属や金額に対して承認者が違う
重複申請 同じ領収書や明細が二重に申請されている

コメントだけで差し戻し理由を書くと、後から集計しづらくなります。

差し戻しカテゴリと自由記述の補足を分けます。

集計・支払・会計連携

経費精算は、承認されて終わりではありません。

承認後に、支払対象として集計し、支払済みにし、会計ソフトへ渡す必要があります。

段階 やること
承認済み 上長・経理の確認が完了した状態
支払対象 締め日や支払方法ごとに集計された状態
支払依頼 振込、給与精算、現金精算の依頼状態
支払済み 実際に精算が完了した状態
会計連携済み freee等へ仕訳候補や経費データが渡った状態
連携エラー 科目、税区分、部門、証憑などで失敗した状態

支払集計アプリを作る場合は、次の項目を持ちます。

フィールド 設計意図
精算締め日 日付 どの締めで支払うか
支払予定日 日付 いつ支払うか
支払方法 ドロップダウン 振込、給与精算、現金
対象申請 関連レコード 承認済み申請を紐づける
支払合計 数値 支払対象金額
支払状態 ステータス 集計中、支払依頼済み、支払済み
会計連携状態 ドロップダウン 未連携、連携済み、エラー
エラー内容 文字列複数行 科目未設定、税区分不備など

freeeなどの会計ソフトへ連携する場合は、kintone側の項目を会計側の項目に対応させます。

kintone側 会計側で必要になりやすいもの
経費日 発生日
申請者・部門 部門、メモ、取引先、従業員
経費区分 勘定科目、補助科目、税区分
金額 取引金額
証憑 ファイル、証憑保存、添付
支払方法 決済口座、未払、給与精算
案件・プロジェクト 品目、メモ、タグ、管理会計項目

kintone予実管理の設計方法でも触れたように、管理科目と会計上の勘定科目は分けることがあります。

経費精算でも同じです。

現場は「広告費」「移動費」「出張費」として入力したい。

会計では、勘定科目、補助科目、税区分、取引先、インボイス確認が必要になる。

ここを同じ項目にすると、申請者にも経理にも負担が出ます。

申請者向けの分類と、会計連携用の分類を分けます。

専用経費精算SaaSへ逃がすケース

kintone経費精算は便利ですが、万能ではありません。

次の条件があるなら、専用経費精算SaaSを検討します。

条件 専用SaaSを検討する理由
電子帳簿保存に本格対応したい 証憑保存、検索、訂正削除履歴などの機能が重要
インボイス確認を効率化したい 登録番号、税率、記載事項の確認が必要
OCRで領収書を読み取りたい 画像補正、金額読取、修正UIが必要
ICカード・クレカ連携が必要 明細取込、重複申請防止、突合が必要
複数段階の承認が多い 代理承認、条件分岐、監査ログが複雑
給与・振込・会計連携まで一体でやりたい 支払処理まで含む運用が必要
経費件数が多い 入力・確認・証憑管理の専用UIが効く

マゴノテの経費精算書アプリテンプレートでは、多事業所のスタッフがPC、タブレット、スマートフォンから申請・承認し、登録と同時に集計できる構成が紹介されています。

マゴノテ:経費精算書アプリ

このようなテンプレートは、初期導入の入口として有用です。

ただし、会計連携、証憑保存、インボイス、給与・振込連携まで含めるなら、テンプレートだけで完結するかは別途確認が必要です。

アクロビジョンのkintone経費精算ページでも、サンプルやカスタマイズで経費精算アプリを作る支援が紹介されています。

アクロビジョン:kintone経費精算

選ぶべきなのは、「kintoneか専用SaaSか」の二択ではありません。

現場の申請受付や社内承認はkintone。

証憑保存、OCR、インボイス確認、会計連携は専用SaaS。

このように分担する方法もあります。

権限設計と個人情報の扱い

経費精算には、個人の移動、取引先、支払先、領収書、場合によっては口座情報が含まれます。

全員に見せる前提で作らない方がよいです。

役割 見せる範囲
申請者 自分の申請、明細、差し戻し理由
上長 自チームの申請、承認に必要な明細
経理 全申請、証憑、科目、支払、連携状態
管理部門 規定、承認ルート、支払対象
税理士・会計担当 必要な証憑、会計連携、確認対象
一般社員 原則、他人の経費は見せない

kintoneでは、アプリ、レコード、フィールドのアクセス権を設定できます。

kintoneヘルプ:アクセス権の設定

経費精算では、特に次の項目に注意します。

  • 申請者本人以外に明細を見せる範囲
  • 領収書画像や請求書PDFの閲覧範囲
  • 口座情報や支払先情報を持つかどうか
  • 上長が経理用の科目や税区分まで見られる必要があるか
  • 退職者や異動者の過去申請をどう扱うか
  • CSV出力や会計連携の権限を誰に持たせるか

権限設計を後回しにすると、経費情報が見えすぎるか、経理が必要な確認をできないかのどちらかになります。

アプリを作る前に、役割ごとの閲覧範囲を決めます。

よくある失敗パターン

kintone経費精算でよくある失敗は、申請フォームだけを作って終わることです。

失敗 起きること 対策
申請と明細を同じ項目にする 複数明細、税区分、証憑確認に弱くなる 申請ヘッダーと明細を分ける
証憑を添付するだけにする 確認状態や不備理由が残らない 証憑確認状態を持つ
社内規定を自由記述で運用する 承認者や経理の判断がぶれる 規定チェック項目を作る
承認済みで終わる 支払や会計連携に進まない 精算集計と支払状態を持つ
差し戻し理由をコメントだけにする 不備の傾向が見えない 差し戻しカテゴリを持つ
会計科目を申請者に直接選ばせる 入力ミスや判断負荷が増える 申請区分と会計科目候補を分ける
電子帳簿保存やインボイスを軽く見る 後で証憑管理を作り直す 経理・税理士と要件を確認する
専用SaaS領域まで作り込む OCR、ICカード、振込、監査ログが重くなる 専用SaaSや会計ソフトと分担する

特に避けたいのは、「承認フローを作れば経費精算になる」と考えることです。

承認フローは重要です。

しかし、経費精算で本当に必要なのは、申請、証憑、規定、承認、支払、会計がつながることです。

承認済みでも、証憑不備、会計科目不明、支払未処理、連携エラーが残っていれば、経費精算は終わっていません。

1週間で始めるならこの順番

最初から専用経費精算SaaSと同じ機能を作る必要はありません。

まずは、申請、承認、経理確認、支払対象の集計までを小さく検証します。

日程 やること 成果物
1日目 経費精算の対象を絞る 交通費、出張費、備品、会議費など
2日目 申請ヘッダーと明細の単位を決める 申請、明細、証憑の構成
3日目 社内規定を整理する 上限、承認者、証憑要否、支払方法
4日目 承認フローと差し戻し理由を決める 上長承認、経理確認、差し戻し
5日目 支払集計を設計する 締め日、支払予定日、支払状態
6日目 会計連携の項目を整理する 勘定科目、税区分、部門、証憑
7日目 実データで試す 入力負荷、不備、支払集計、連携エラーを確認

最初の検証では、全経費を対象にしない方がよいです。

交通費だけ、出張精算だけ、備品購入だけなど、件数がありつつルールが比較的分かりやすい範囲から始めます。

そこで、次の確認をします。

  • 申請者が迷わず入力できるか
  • 明細ごとに証憑を確認できるか
  • 上長と経理の確認観点が分かれているか
  • 差し戻し理由が再申請に使えるか
  • 支払対象を締め日ごとに集計できるか
  • 会計ソフトへ渡す項目がそろっているか
  • 専用SaaSに任せるべき要件が出ていないか

この確認で詰まるところが、本格実装前に設計すべき論点です。

実装前チェックリスト

kintone経費精算を実装する前に、次の項目を確認します。

  • 経費精算の対象が、交通費、出張費、備品、会議費などのどれか決まっている
  • 申請ヘッダーと経費明細を分けるか決まっている
  • 証憑を明細単位で管理するか、申請単位で管理するか決まっている
  • 領収書・請求書の保存方針を経理・税理士と確認している
  • インボイス確認が必要な経費の扱いが決まっている
  • 社内規定の上限、日当、交通費、交際費のルールが整理されている
  • 自動判定する経費と、人が確認する経費が分かれている
  • 上長承認と経理確認の役割が分かれている
  • 差し戻し理由をカテゴリで残せる
  • 支払対象の締め日、支払方法、支払状態が決まっている
  • freee等へ連携する場合、勘定科目、税区分、部門、証憑の対応が決まっている
  • 連携ログで成功、失敗、再実行を追える
  • 申請者、上長、経理、管理者の閲覧権限が決まっている
  • 専用経費精算SaaSへ任せるべき範囲を決めている
  • kintoneだけで電子帳簿保存やインボイス対応を完結させる前提にしていない

このチェックリストで詰まるところが、kintoneの設定前に決めるべきことです。

特に、証憑保存、会計連携、支払状態、権限設計は後から直すと重くなります。

過去の経費データが積み上がる前に決めます。

まとめ

kintoneで経費精算を作ること自体は難しくありません。

申請者、日付、金額、用途、領収書、承認者を入れれば、経費精算アプリは作れます。

しかし、実務で使える経費精算にするには、申請フォームだけでは足りません。

必要なのは、申請ヘッダー、経費明細、証憑、社内規定、承認、支払、会計連携、専用SaaSとの境界を決めることです。

kintoneは、社内の申請、承認、差し戻し、経理確認、支払対象の集計に向いています。

一方で、電子帳簿保存、インボイス確認、OCR、ICカード連携、給与・振込連携、正式な仕訳や帳簿は、専用経費精算SaaSや会計ソフトを正本にした方がよい領域です。

経費精算をkintoneで始めるなら、まず次の3つを決めてください。

  • 申請、明細、証憑をどの単位で分けるか
  • 承認済みから支払・会計連携までをどうつなぐか
  • kintoneで持つ範囲と、専用SaaS・会計ソフトへ任せる範囲をどこで分けるか

この3つが決まっていれば、kintone経費精算は単なる承認フォームではなく、経理確認と会計連携まで見通せる業務システムになります。

逆に、ここを曖昧にしたまま申請フォームだけ作ると、承認は通っているのに、証憑確認、支払、会計登録、税務確認が後ろで詰まります。

経費精算は、申請を通す仕事ではありません。

経費の根拠を確認し、社内規定に沿って承認し、支払と会計へ正しく渡す業務です。

kintone業務アプリ設計支援

kintone経費精算を実務で回る業務システムとして設計します

経費精算アプリを作るだけで終わらせず、証憑、承認、差し戻し、支払集計、会計連携、専用SaaSとの分担まで一緒に落とし込みます。

著者
守高 成悟
守高 成悟

代表取締役 CEO

千葉県出身。10歳の頃からプログラミングを始め、ゲーム、Webサイト、ロボット、スマホアプリなどを制作。大阪大学基礎工学部情報科学科で情報工学と統計学を学び、大学時代はAIを研究。大学在学中にWeb広告代理店でのインターンや人材系Webサービスの立ち上げを経験し、卒業後はフリーランスエンジニアとしてGISシステム、データ基盤構築、Webシステムの開発に従事。10年以上のWebアプリ開発・データ分析経験を基に、2023年9月に株式会社ビットライトを設立し、現場業務の仕組み化からデータ基盤構築、データ活用支援までを一気通貫で支援。

運営会社
株式会社ビットライト
株式会社ビットライト

顧客が本当に必要だった価値を、実装する。

現場業務の仕組み化からデータ基盤構築、データ活用支援までを一気通貫で支援しています。

コーポレートサイトを見る
kintone設計相談

アプリ構成・権限・連携範囲を相談できます

Excelからの移行、既存kintoneの見直し、外部サービス連携まで、業務に合わせた設計範囲を整理します。