IoTデバイス×ブロックチェーンで実現する社内通貨システム~在室検知からトークン発行まで~
2025-10-20 勉強会
はじめに
デジタル通貨やブロックチェーンが社会実装の段階に入りつつあり、企業レベルでの具体的な実証が進み始めています。
パナソニックでは、観光客向けの「トークン型周遊パス」を DCJPY(デジタル通貨)基盤上で実証し、使い残しの返金や地域事業者への決済をスマートコントラクトで自動化する取り組みを行っていました。
支払いの流れや取引履歴をブロックチェーン上に記録し、関係者が参照できるようにすることで、透明性と信頼性を高めた地域通貨モデルの可能性を検証していたこの取り組みはとても興味惹かれるものでした
支払いの流れや取引履歴をブロックチェーン上に記録し、関係者が参照できるようにすることで、透明性と信頼性を高めた地域通貨モデルの可能性を検証していたこの取り組みはとても興味惹かれるものでした
また IIJ(インターネットイニシアティブ)も同じく 「環境価値のデジタル資産化および DCJPY による決済取引開始」を発表しています。
内容としては、非化石証書などの環境価値をブロックチェーン上でデジタル化し、DCJPYネットワークでの決済に活用するというものです。
※非化石証書:再生可能エネルギーなど CO₂を排出しない電力 に由来する「環境価値」を、電力そのものとは別に「証書」として取引できるようにしたもの
こうした動きからも、ブロックチェーンやデジタル通貨はすでに実験段階を越え、社会的な価値の流通を担う現実的な技術になりつつあると感じます。
その上で、この技術を「社内のリアルな課題」にどう活かせるかを考えました。
単なるテクノロジーのデモではなく、「出社や残業にかかるコストをどう正当に評価できるか?」という日常的な課題を出発点にしてみました。
内容としては、非化石証書などの環境価値をブロックチェーン上でデジタル化し、DCJPYネットワークでの決済に活用するというものです。
※非化石証書:再生可能エネルギーなど CO₂を排出しない電力 に由来する「環境価値」を、電力そのものとは別に「証書」として取引できるようにしたもの
こうした動きからも、ブロックチェーンやデジタル通貨はすでに実験段階を越え、社会的な価値の流通を担う現実的な技術になりつつあると感じます。
その上で、この技術を「社内のリアルな課題」にどう活かせるかを考えました。
単なるテクノロジーのデモではなく、「出社や残業にかかるコストをどう正当に評価できるか?」という日常的な課題を出発点にしてみました。
背景:出社と残業に潜むコスト
ある日のとある社員の会社での食生活を眺めながら、思いを巡らせてみました。
昼:はるきの弁当 550円
夜:はるきの弁当 550円 + モンスター 230円
合計:1,330円
昼に続いて、夜も、はるきのから揚げ弁当
そして眠気覚ましのためのみんな大好きモンスター
会社にくるから発生するコスト、、というのは確実に存在していて、リモートワークだと飲まないモンスターも、会社に来るとなぜか眠気覚ましのために必要になります
ラムネを摂取したり、ジュースの本数も増えていきます。
嗜好品としての意味合いが強いものですが、会社に来なければ発生しなかったこれらのものは本当にただの嗜好品なのか、、?
次にここに発生した現金に目を向けたいと思います
この日の負担は、唐揚げ弁当2個とモンスターで、1330円ほどになりますが、1330円の現金を得るために、年収400万円程度の人だと、会社の負担も合わせると、854円もの税金が取られている計算になるそうです(AI調べ)
合計2184円
ラムネを摂取したり、ジュースの本数も増えていきます。
嗜好品としての意味合いが強いものですが、会社に来なければ発生しなかったこれらのものは本当にただの嗜好品なのか、、?
次にここに発生した現金に目を向けたいと思います
この日の負担は、唐揚げ弁当2個とモンスターで、1330円ほどになりますが、1330円の現金を得るために、年収400万円程度の人だと、会社の負担も合わせると、854円もの税金が取られている計算になるそうです(AI調べ)
合計2184円
もう1個大盛りの唐揚げ弁当食べることができちゃいますね
今後、唐揚げ弁当2つ食べる度に私たちは、大盛り唐揚げ弁当1つが羽が生えて空を飛んでいくことを思い出すことになるでしょう
年収が上がるほど、負担率はさらに高まり、年収800万円の場合は約1.9倍にも負担率が跳ね上がります。
もちろんその税金を使って様々な社会インフラが維持されているから日本はこれだけ住みやすい国になれてるので、恩恵も受けられていることも忘れてはいないのですけど、、、なんかこう、、こういう社内で循環するものについては、余計な税金取られず満額社員に還元できないものかなーと
今後、唐揚げ弁当2つ食べる度に私たちは、大盛り唐揚げ弁当1つが羽が生えて空を飛んでいくことを思い出すことになるでしょう
年収が上がるほど、負担率はさらに高まり、年収800万円の場合は約1.9倍にも負担率が跳ね上がります。
もちろんその税金を使って様々な社会インフラが維持されているから日本はこれだけ住みやすい国になれてるので、恩恵も受けられていることも忘れてはいないのですけど、、、なんかこう、、こういう社内で循環するものについては、余計な税金取られず満額社員に還元できないものかなーと
社内の課題:残業する人へのケア
もう一つ感じていたのは、「残業している人へのケア」という社内の課題です。
残業している人に何かあげたいと思っても、現実は簡単ではないです。
人事考課で残業を評価するようにしてしまうと、残業を推奨するメッセージになりかねず、また働き方改革の流れもあり、残業は“減らすべきもの”という暗黙の前提があります。
でも、なんやかんや言っても、避けられない残業やサポート業務を担う人は確実に存在してます。
そしてそういう人たちは毎日定時に帰ることができる人たちよりも、金銭的・肉体的な負担を追っていただいてます。
このジレンマの中で、「残業を奨励せずに、残業せざるを得なかった人をどう労うか」の答えを見つけていきたく、その観点で在室ポイントは、より長く会社にいてくれる人をねぎらう仕組みになれるのではないかと考えています
※時間内に仕事をしっかり終えてくれてる人もまた正しく評価されなければならないので、時間だけを評価軸に置く意図ではありません
※家の事情で仕事を持ち帰って家で頑張ってくれてる人も評価できる仕組みも別途検討したいです
残業している人に何かあげたいと思っても、現実は簡単ではないです。
人事考課で残業を評価するようにしてしまうと、残業を推奨するメッセージになりかねず、また働き方改革の流れもあり、残業は“減らすべきもの”という暗黙の前提があります。
でも、なんやかんや言っても、避けられない残業やサポート業務を担う人は確実に存在してます。
そしてそういう人たちは毎日定時に帰ることができる人たちよりも、金銭的・肉体的な負担を追っていただいてます。
このジレンマの中で、「残業を奨励せずに、残業せざるを得なかった人をどう労うか」の答えを見つけていきたく、その観点で在室ポイントは、より長く会社にいてくれる人をねぎらう仕組みになれるのではないかと考えています
※時間内に仕事をしっかり終えてくれてる人もまた正しく評価されなければならないので、時間だけを評価軸に置く意図ではありません
※家の事情で仕事を持ち帰って家で頑張ってくれてる人も評価できる仕組みも別途検討したいです
発想:社内でお金を回す仕組み
毎月一定額発生している会社内で使うお金(食事代・ドリンク代)が「給料」ではなく「福利厚生」として提供できたら、税金に取られてしまう割合を下げもっと多くを社員に還元できるのではないか
従来:
給与支給 → 税・保険料控除 → 手取り → 弁当購入(課税)
理想:
福利厚生として支給 → 非課税で利用 → 弁当購入(社内完結)
税や保険料として外部に流れる分を減らし、
会社内でお金が循環する仕組みを作る。
その実験的なアプローチとして「社内通貨制度」を考えました。
会社内でお金が循環する仕組みを作る。
その実験的なアプローチとして「社内通貨制度」を考えました。
コンセプト:社内通貨制度とは
社内通貨「InterPark Token(IPT)」を発行する案を考えてみました。
IPTの付与タイミングはいろいろ工夫できますが、まずは 出社や在室時間に応じて自動的に付与される仕組みで試してみようと考えています。
・会社側では福利厚生費として処理できる可能性(損金算入の可否は制度設計や税務上の取扱い次第)
・社員は原則非課税での利用を想定(給与所得とみなされないための条件や月ごとの上限など、法令上の整理が必要)
・利用範囲は社内限定(「オフィスおかん」や軽食・飲料など、ちょっとした福利厚生的な用途を想定)
・取引履歴はブロックチェーン上に記録(透明性の確保と改ざん防止の観点)
この仕組みがうまく機能すれば、働くことに伴う見えないコストを可視化し、新しい報酬設計のあり方を模索できるかもしれません。
※上記はあくまで概念実証(PoC)段階での設計方針であり、実際の運用の際は税務処理について専門家との確認を行いながら検討する必要があります
IPTの付与タイミングはいろいろ工夫できますが、まずは 出社や在室時間に応じて自動的に付与される仕組みで試してみようと考えています。
・会社側では福利厚生費として処理できる可能性(損金算入の可否は制度設計や税務上の取扱い次第)
・社員は原則非課税での利用を想定(給与所得とみなされないための条件や月ごとの上限など、法令上の整理が必要)
・利用範囲は社内限定(「オフィスおかん」や軽食・飲料など、ちょっとした福利厚生的な用途を想定)
・取引履歴はブロックチェーン上に記録(透明性の確保と改ざん防止の観点)
この仕組みがうまく機能すれば、働くことに伴う見えないコストを可視化し、新しい報酬設計のあり方を模索できるかもしれません。
※上記はあくまで概念実証(PoC)段階での設計方針であり、実際の運用の際は税務処理について専門家との確認を行いながら検討する必要があります
トークン残高の確認:MetaMaskによる可視化
Chromeの拡張機能のMetaMask(メタマスク)を使えば、より直感的に残高を確認できます。
MetaMaskは、EthereumやHyperledger BesuのようなEVM互換ネットワークに接続できるウォレットです。
ネットワーク設定を手動で追加することで、社内環境のBesuノードにも接続できます。
MetaMaskは、EthereumやHyperledger BesuのようなEVM互換ネットワークに接続できるウォレットです。
ネットワーク設定を手動で追加することで、社内環境のBesuノードにも接続できます。
システムの概要
システムの流れは次の通りです。
・社員証に BLEビーコン(FSC-BP103) を装着
・ESP32-C3 デバイスがBLE信号を検知
・AWS EC2上にデータ送信
・Hyperledger Besu(プライベートブロックチェーン) でトランザクション生成
・Solidityコントラクト(SimpleToken.sol) が mint() を実行しトークン発行
・MetaMask で残高確認
在室時間がIPT(InterPark Token)として可視化される流れです。
・社員証に BLEビーコン(FSC-BP103) を装着
・ESP32-C3 デバイスがBLE信号を検知
・AWS EC2上にデータ送信
・Hyperledger Besu(プライベートブロックチェーン) でトランザクション生成
・Solidityコントラクト(SimpleToken.sol) が mint() を実行しトークン発行
・MetaMask で残高確認
在室時間がIPT(InterPark Token)として可視化される流れです。
IoTデバイス開発の挑戦
なぜIoTを選んだのか
BLEビーコンによる在室検知は、シンプルながら非常に現実的な方法だと思いました。
単なる位置情報トラッキングではなく、「一定の範囲内にいる/いない」を判定するだけの設計にすることで、必要以上に個人の行動を監視しないバランスが取れると感じました。
AirTagのような高精度トラッキングデバイスだと、自宅や移動経路などプライベートな行動まで把握できてしまう可能性があり、社員にとって心理的安全性を確保しづらいと考えました。
そのため、今回のシステムでは「在室しているかどうか」だけを判定する仕組みにとどめ、“検知される安心感”と“監視されない安心感”の両立を意識しています。
実際に動くデバイスを作りながら、技術と倫理の線引きをどう設計に落とし込むかを考えるきっかけにもなりました。
単なる位置情報トラッキングではなく、「一定の範囲内にいる/いない」を判定するだけの設計にすることで、必要以上に個人の行動を監視しないバランスが取れると感じました。
AirTagのような高精度トラッキングデバイスだと、自宅や移動経路などプライベートな行動まで把握できてしまう可能性があり、社員にとって心理的安全性を確保しづらいと考えました。
そのため、今回のシステムでは「在室しているかどうか」だけを判定する仕組みにとどめ、“検知される安心感”と“監視されない安心感”の両立を意識しています。
実際に動くデバイスを作りながら、技術と倫理の線引きをどう設計に落とし込むかを考えるきっかけにもなりました。
使用デバイス:FSC-BP103
在室検知の中心となるデバイスは、中国 Shenzhen Feasycom Technology 社の「FSC-BP103」 BLEビーコン です。
主な特徴は以下の通りです。
・スマホアプリから操作可能 – 設定やUUIDの変更が簡単で、導入がスムーズ。
・小型・軽量 – 社員証や名札に違和感なく装着できるサイズ。
・低消費電力 – 長期間バッテリーで稼働し、メンテナンス負担を軽減。
・BLE 5.0対応 – 通信安定性と範囲が向上。
・カスタマイズ可能 – UUID/Major/Minor値を組織ごとに設定可能。
・価格 – 1,899円(税込)と、PoCや小規模導入にも現実的なコスト
実際の運用では、社員証にこのビーコンを取り付けて在室を検知し、必要に応じてスマホアプリから状態を確認・設定できます。
・スマホアプリから操作可能 – 設定やUUIDの変更が簡単で、導入がスムーズ。
・小型・軽量 – 社員証や名札に違和感なく装着できるサイズ。
・低消費電力 – 長期間バッテリーで稼働し、メンテナンス負担を軽減。
・BLE 5.0対応 – 通信安定性と範囲が向上。
・カスタマイズ可能 – UUID/Major/Minor値を組織ごとに設定可能。
・価格 – 1,899円(税込)と、PoCや小規模導入にも現実的なコスト
実際の運用では、社員証にこのビーコンを取り付けて在室を検知し、必要に応じてスマホアプリから状態を確認・設定できます。
スマホアプリFeasyBeacon
使用デバイス:ESP32-C3
ビーコン単体では通信機能を持たないため、検知側として Seeed XIAO ESP32-C3 を採用しました。
実運用になると、執務室内にも複数個必要となり、また、離れた各会議室でも検知が必要になるので、安価に設置が可能な装置としてこちらが適していると考えました
実運用になると、執務室内にも複数個必要となり、また、離れた各会議室でも検知が必要になるので、安価に設置が可能な装置としてこちらが適していると考えました
・WiFi + Bluetooth LE 内蔵
・小型(約2cm × 3cm)・低価格 1,498円(税込)
・低消費電力設計
ESP32-C3がFSC-BP103の発信をスキャンし、AWS EC2上へWiFi経由で送信。データはブロックチェーン(Hyperledger Besu)へトランザクションとして記録され、在室に応じたトークン(IPT)が発行されます。
10年ほど前の勉強会で見せたRaspberry Piを使うこともできましたが、Raspberry Piは「小さなパソコン」なので、今回のように“ビーコンを検知してデータを送る”という単機能の用途では、ESP32-C3の軽さとシンプルさがちょうどよかったと感じました。
開発環境:Arduino IDE
開発にはArduino IDE(ESP32-C3対応版)を使用しました。
Arduino IDEは、コード作成からデバイス書き込みまでを一貫して行えるシンプルな統合開発環境です。
Arduino IDEは、コード作成からデバイス書き込みまでを一貫して行えるシンプルな統合開発環境です。
Wi-Fi通信(WiFi.h)やBLEスキャン(BLEDevice.h)などのライブラリを手軽に扱える点が魅力で、C++ベースのスケッチを書くだけでIoTデバイスを動かせます。
今回はメモリ制約に配慮し、HTTPClientを使わずにWiFiClientでリクエストを直接構築しました。
シリアルモニターでログを確認しながら動作を追うことで、実機開発の感覚を掴むことができました。
今回はメモリ制約に配慮し、HTTPClientを使わずにWiFiClientでリクエストを直接構築しました。
シリアルモニターでログを確認しながら動作を追うことで、実機開発の感覚を掴むことができました。
通信設計の試行錯誤:AWS IoTとの接続
本来は、より軽量なプロトコルである MQTT を使って、AWS IoT Core との直接通信を行う構想でした。
MQTTはHTTPよりも通信オーバーヘッドが小さく、IoTデバイス向けに最適化された「発行/購読」型の仕組みを備えています。
しかし実際には、AWS IoTが利用する 8883番ポートの通信がどうしても安定せず、接続確立の途中でセッションが切断されてしまう問題に直面しました。
ファイアウォール設定や証明書の検証など、いくつかの対策を試みましたが、最終的には HTTP経由でのFlask API送信方式に切り替えました。
この選択によって、構成はやや重くなりましたが、Flask側でデータ整形とブロックチェーン送信を一括処理できるようになり、デバッグ性と可視性の高い実装に落ち着いたと思います。
MQTTはHTTPよりも通信オーバーヘッドが小さく、IoTデバイス向けに最適化された「発行/購読」型の仕組みを備えています。
しかし実際には、AWS IoTが利用する 8883番ポートの通信がどうしても安定せず、接続確立の途中でセッションが切断されてしまう問題に直面しました。
ファイアウォール設定や証明書の検証など、いくつかの対策を試みましたが、最終的には HTTP経由でのFlask API送信方式に切り替えました。
この選択によって、構成はやや重くなりましたが、Flask側でデータ整形とブロックチェーン送信を一括処理できるようになり、デバッグ性と可視性の高い実装に落ち着いたと思います。
諦めきれず、別の方法でAWS IoTとの疎通を検証
とはいえ「なぜ接続できないのか」をどうしても確かめたく、Docker上でAWS IoT接続の再現環境を構築して検証を行いました。
ESP32-C3実機ではTLSハンドシェイクや証明書の扱いが制約されてしまうため、一度PC上のLinuxコンテナで Mosquitto(MQTTクライアント)+AWS IoT証明書 を使い、同じエンドポイント・同じポートで通信テストを実施しました。
結果として、PC環境からは正常に接続できたため、問題はESP32-C3側の 暗号処理スタックの制約(メモリ不足またはTLS実装差異) に起因している可能性が高いと考えています。
この検証を通して、「軽量デバイスでAWS IoTを直接扱う難しさ」 を実感しました。
とはいえ、Dockerによる再現実験で原因の切り分けができたことで、次のステップ(中継サーバ経由のMQTT変換)に進む道筋が見えたと思います。
ESP32-C3実機ではTLSハンドシェイクや証明書の扱いが制約されてしまうため、一度PC上のLinuxコンテナで Mosquitto(MQTTクライアント)+AWS IoT証明書 を使い、同じエンドポイント・同じポートで通信テストを実施しました。
結果として、PC環境からは正常に接続できたため、問題はESP32-C3側の 暗号処理スタックの制約(メモリ不足またはTLS実装差異) に起因している可能性が高いと考えています。
この検証を通して、「軽量デバイスでAWS IoTを直接扱う難しさ」 を実感しました。
とはいえ、Dockerによる再現実験で原因の切り分けができたことで、次のステップ(中継サーバ経由のMQTT変換)に進む道筋が見えたと思います。
WSL上では、Bluetoothを検出するのが難しかったため、Windows側のPowershellでBLEスキャンを行い、WSLのコンテナでAWS IoT/EC2にデータを送出するコンテナを動かしました。
※PCでやろうとしたら、これだけのプロセスが必要になるものを、小さなIoT機器1つ実現することができるのはとても効率が良いことだとあらためて痛感しました
小さなボードの中で「何を削り、どう動かすか」を考えるのは、ソフトウェアとは違う面白さがありました。
※PCでやろうとしたら、これだけのプロセスが必要になるものを、小さなIoT機器1つ実現することができるのはとても効率が良いことだとあらためて痛感しました
小さなボードの中で「何を削り、どう動かすか」を考えるのは、ソフトウェアとは違う面白さがありました。
ブロックチェーン構成:Hyperledger Besu
BesuはEthereum互換のプライベートチェーンで、MetaMaskやweb3.pyと同じプロトコルで通信できます。
選定理由は、
・Ethereumとの互換性
・将来的なPolygonやOptimismへの移行のしやすさ
・開発者コミュニティの豊富さ
開発モード(--network=dev)で高速化し、PoA(Proof of Authority)により即時確定させました。
PoAは、信頼されたノード(管理者)がブロックを生成・検証する合意方式で、マイニング競争を行う PoW(Proof of Work) や、トークンの保有量で検証権を得る PoS(Proof of Stake) と比べて、軽量で電力消費が少なく、社内など限定環境での運用に適していると考えています。
PoWやPoSのように「誰でも参加できる分散性」は高くありませんが、その分、トランザクションの処理速度が速く、ノードの管理や障害対応が容易という実務的な利点があります。
今回は社内PoCという前提もあり、まずは安定性・運用効率を優先し、信頼されたノードによる合意形成(PoA)を採用するのが最も現実的だと思いました。
選定理由は、
・Ethereumとの互換性
・将来的なPolygonやOptimismへの移行のしやすさ
・開発者コミュニティの豊富さ
開発モード(--network=dev)で高速化し、PoA(Proof of Authority)により即時確定させました。
PoAは、信頼されたノード(管理者)がブロックを生成・検証する合意方式で、マイニング競争を行う PoW(Proof of Work) や、トークンの保有量で検証権を得る PoS(Proof of Stake) と比べて、軽量で電力消費が少なく、社内など限定環境での運用に適していると考えています。
PoWやPoSのように「誰でも参加できる分散性」は高くありませんが、その分、トランザクションの処理速度が速く、ノードの管理や障害対応が容易という実務的な利点があります。
今回は社内PoCという前提もあり、まずは安定性・運用効率を優先し、信頼されたノードによる合意形成(PoA)を採用するのが最も現実的だと思いました。
besu:
image: hyperledger/besu:latest
container_name: ec2-besu-prod
command: >
--network=dev # 開発用ネットワーク
--rpc-http-enabled # HTTP RPC API有効化
--rpc-http-host=0.0.0.0 # 全IPから接続許可
--rpc-http-port=8545 # HTTP RPCポート
--rpc-http-api=ETH,NET,WEB3,TXPOOL,ADMIN,DEBUG,MINER
--host-allowlist=* # ホスト制限なし
--rpc-http-cors-origins=* # CORS制限なし
--rpc-ws-enabled # WebSocket RPC有効化
--rpc-ws-host=0.0.0.0 # WebSocket接続許可
--rpc-ws-port=8546 # WebSocketポート
--data-path=/data # ブロックチェーンデータの保存場所
--min-gas-price=0 # ガス価格を0に設定(開発用)
--miner-enabled # マイニング有効化
--miner-coinbase=0xCCxxxxxxx # マイニング報酬をいったん自分固定に
ports:
- "8545:8545" # HTTP RPCポート
- "8546:8546" # WebSocketポート
volumes:
- ./besu-dev/data:/data # データ永続化
user: "1002:1002" # ファイル権限の統一
restart: unless-stopped
networks:
- besu-network
ブロックチェーン接続の確認スクリプト
ブロックチェーンの仕組みを理解するうえで、「トランザクションがどのように積み上がっていくか」を確認することは重要だと思いました。
そこで、Besuノードに直接アクセスし、ブロックの連なり(チェーン構造)を確認できる簡易スクリプトを用意しました。
そこで、Besuノードに直接アクセスし、ブロックの連なり(チェーン構造)を確認できる簡易スクリプトを用意しました。
=== ブロックチェーンの繋がり確認 ===
現在のブロック: 0x86990
=== ブロック 0x86990 ===
{
"number": "0x86990",
"hash": "0xd24ef7782701e78fdc5d17afcded0a6214895933f1aee366a9ff329b6524cf78",
"parentHash": "0x12058a251ea6beb7cb1a631e4461cc0546b4b7a09a2c4a0505de26da83852ce6",
"transactionCount": 0
}
=== ブロック 0x8698f ===
{
"number": "0x8698f",
"hash": "0x12058a251ea6beb7cb1a631e4461cc0546b4b7a09a2c4a0505de26da83852ce6",
"parentHash": "0x90e02ce2b8a9ae193de176efdc16a44723d46001da4325530f9847121955c9d2",
"transactionCount": 0
}
=== ブロック 0x8698e ===
{
"number": "0x8698e",
"hash": "0x90e02ce2b8a9ae193de176efdc16a44723d46001da4325530f9847121955c9d2",
"parentHash": "0x6779fc2e17cce74a7fa7696f8194fbccd40b8f076bf563806761c3566670d910",
"transactionCount": 0
}
=== チェーンの繋がり ===
ブロック1 → ブロック2 → ブロック3
↓ ↓ ↓
ハッシュ1 → ハッシュ2 → ハッシュ3
スマートコントラクト実行基盤:EVM(Ethereum Virtual Machine)
BesuはEthereum互換のプライベートブロックチェーンで、その互換性の中心にあるのが EVM(Ethereum Virtual Machine) です。
※GOで書かれたクライアントはGesu/Rustで書かれたのがReth
EVMはブロックチェーン上でプログラム(スマートコントラクト)を実行するための「仮想マシン」で、Solidityで書かれたコードをEVMが理解できる バイトコード に変換して動かします。
つまり、ブロックチェーン上に配置されたコントラクトは、EVMが命令単位で逐次実行し、結果をすべてのノードで同じように再現する仕組み。
この仕組みによって「誰がどのノードで実行しても同じ結果が得られる」ことが保証され、改ざんできない自動実行環境が成り立ちます。
Hyperledger BesuはこのEVMを完全に実装しているため、Ethereum本体やPolygon、Optimismなどと同じスマートコントラクトを動かすことができるのが強みです。
これにより、
・Solidityで開発したコントラクトをそのまま再利用できる
・既存のツール(web3.py、MetaMask、Remixなど)を活用できる
・将来的なL2ネットワークや他チェーンへの移行が容易
といった利点が得られます。
※GOで書かれたクライアントはGesu/Rustで書かれたのがReth
EVMはブロックチェーン上でプログラム(スマートコントラクト)を実行するための「仮想マシン」で、Solidityで書かれたコードをEVMが理解できる バイトコード に変換して動かします。
つまり、ブロックチェーン上に配置されたコントラクトは、EVMが命令単位で逐次実行し、結果をすべてのノードで同じように再現する仕組み。
この仕組みによって「誰がどのノードで実行しても同じ結果が得られる」ことが保証され、改ざんできない自動実行環境が成り立ちます。
Hyperledger BesuはこのEVMを完全に実装しているため、Ethereum本体やPolygon、Optimismなどと同じスマートコントラクトを動かすことができるのが強みです。
これにより、
・Solidityで開発したコントラクトをそのまま再利用できる
・既存のツール(web3.py、MetaMask、Remixなど)を活用できる
・将来的なL2ネットワークや他チェーンへの移行が容易
といった利点が得られます。
Remix IDEでスマートコントラクトをテスト
https://remix.ethereum.org/Remix IDEは、ブラウザ上で動作するブロックチェーン開発環境です。
スマートコントラクトのコーディングをし、コンパイル・デプロイも可能です。
MetaMaskにログインしていれば、「Environment」の「injected Provider -MetaMask」でアカウントが自動連係されます。
スマートコントラクトのコーディングをし、コンパイル・デプロイも可能です。
MetaMaskにログインしていれば、「Environment」の「injected Provider -MetaMask」でアカウントが自動連係されます。
関数にあわせて値を入力しテストすることができますので、ここでテストして問題のなかったコードをデプロイする運用
トークン発行のコントラクト
contract SimpleToken {
mapping(address => uint256) public balanceOf;
address public owner;
constructor() { owner = msg.sender; }
function mint(address to, uint256 amount) public onlyOwner {
balanceOf[to] += amount;
}
}
このmint()が「IPTを発行する関数」で、IoTデバイスからFlaskを経由して自動的に呼び出されます。
トランザクションの実例
ブロックチェーンには、次のように記録されます。
{
"hash": "0x7d4dee8a...",
"from": "0xFE3B557E...",
"to": "0x156C51D8...",
"function": "mint(0x42cbe2B3..., 125000000000000000)",
"status": "success",
"timestamp": "2025-10-13 09:56:07"
}
誰が・いつ・いくら発行したかが永続的に保存され、削除も改ざんもできません。
「信頼できる勤怠記録」として応用できる可能性も感じました。
「信頼できる勤怠記録」として応用できる可能性も感じました。
報酬の仕組み
在室検知ごとに自動で mint() が実行され、指定アドレスにIPTが送られます。
0x1BC16D674EC8000 (16進数)
= 125,000,000,000,000,000 wei
= 0.125 IPT
1回の検知ごとに0.125 IPTが付与される設定で、在室時間がそのまま「トークン残高」として反映されます。
付与されたIPTはMetamaskで確認することが可能です
システムの全体像
まとめ
今回は時間の関係上、社内通貨(IPT)の付与までを実装範囲としました。
IoTデバイスによる在室検知と、ブロックチェーンを活用したトークン発行の一連の仕組みを通して、日々の行動や貢献をデジタルに記録する仕組みの概念実証を行いました。
評価制度は多くの場合、成果や目に見える行動を基準に設計されています。
一方で、チームを支えたり、誰かの課題をさりげなく解決したりといった定量化しにくい貢献も数多く存在します。
IoTやブロックチェーンといった技術を使うことで、そうした見えにくい努力をデータとして補足し、より公正な評価につなげることができるかもしれません。
IoTデバイスによる在室検知と、ブロックチェーンを活用したトークン発行の一連の仕組みを通して、日々の行動や貢献をデジタルに記録する仕組みの概念実証を行いました。
評価制度は多くの場合、成果や目に見える行動を基準に設計されています。
一方で、チームを支えたり、誰かの課題をさりげなく解決したりといった定量化しにくい貢献も数多く存在します。
IoTやブロックチェーンといった技術を使うことで、そうした見えにくい努力をデータとして補足し、より公正な評価につなげることができるかもしれません。